Re: L2R/R2L syntax
On Mon, Jan 20, 2003 at 07:27:56PM -0700, Luke Palmer wrote:
> > What benefit does C<< <~ >> bring to the language?
>
> Again, it provides not just a "null operator" between to calls, but
> rather a rewrite of method call syntax. So:
>
> map {...} <~ grep {...} <~ @boing;
>
> is not:
>
> map {...} grep {...} @boing;
>
> But rather:
>
> @boing.map({...}).grep({...});
This is not a for or against, but there is something that has been
bugging me about this.
Currently in Perl5 it is possible to create a sub that has map/grep-like
syntax, take a look at List::Util
If the function form of map/grep were to be removed, which has been suggested,
and the <~ form maps to methods. How would you go about defining a utility
module similar to List::Util that uses the same syntax as map/grep but
without making the subs methods on the global ARRAY package ?
Graham.
Re: A proposal on if and else
"Joseph F. Ryan" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Rafael Garcia-Suarez wrote: > > > >The tokeniser could send two tokens "else" and "if" whenever it > >recognizes the keyword "elsif" -- so this isn't a problem. > > > > I think the point of having C as a sub rather than as a separate > syntax is so the parser doesn't have to do anything special for > special keywords. The specialness could be generalized, so that its no longer a parser hack: #define elsif else if Dave.
Re: L2R/R2L syntax
> Date: Tue, 21 Jan 2003 10:04:58 +
> From: Graham Barr <[EMAIL PROTECTED]>
>
> If the function form of map/grep were to be removed, which has been
> suggested, and the <~ form maps to methods. How would you go about
> defining a utility module similar to List::Util that uses the same
> syntax as map/grep but without making the subs methods on the global
> ARRAY package ?
I don't know whether you can use multimethods to do it, but if you
can, it would probably go something like this:
sub wonk (@list: &code) is multi {
grep {!code()} <~ @list
}
So C would be called like a method, but still not have access to
C's private attributes as it's not a part of the class.
I don't know whether I like this or not.
Luke
Re: L2R/R2L syntax
Damian Conway writes:
> Buddha Buck wrote:
> >
> > Perl 5 allows you to do:
> >
> > $object->meth1->meth2->meth3; # Perl5 chained method, L2R
> >
> > Perl 6 will also allow you to do:
> >
> > $data ~> sub1 ~> sub2 ~> sub3;# Perl6 chained subs, L2R
> >
> > Perl 5 allows you to to:
> >
> > sub3 sub2 sub1 $data; # Perl5 chained subs, R2L
> >
> > Perl 6 will also allow you to do:
> >
> > meth3 <~ meth2 <~ meth1 <~ $Xbject # Perl 6 chained methods, R2L
> >
> > All four syntaxes will be available in Perl 6, modulo the fact that '->'
> > is now spelled '.'
> >
> > The additional functionality that when the last sub or method in the ~>
> > and <~ is a variable an assigment is done is a convenience issue.
>
will something like that work ? and how ~> distinguish between = and
:= ?
@source ~> part [
/foo/,
/bar/,
/zap/ ]
~> (@foo,@bar,@zap)
the issue is : what happens if function returns more than one
variables .
It seems that it is not very bad idea to have some special (lexical )
variable similar to $0 for regexes that is set after
grep/part/sort/or_may_be_something_userdefined have done its work and
then ( here $0 is a placeholder for that variable ) :
@source ~> part [
/foo/ => @foo,
/bar/ => @bar
/zap/ => @zap ] ;
$0{'@foo'} ~> map { ... } ~> @foo;
$0{'@bar'} ~> map { ... } ~> @bar;
$0{'@zap'} ~> map { ... } ~> @zap;
but maybe that may be stilll shortened . the idea ( maybe bad ) is to
have "named" or "numbered" (pseudo)pipes similar to having named or
numbered arguments.
@source |> part [
/foo/ => "foo",
/bar/ => "bar"
/zap/ => "zap" ]
|foo> map { ... } |> @foo,
|bar> map { ... } |> @bar,
|zap> map { ... } |> @zap ;
So |foo> is "undone" by perl arranging temporal variable after the
action of part and then feeding this temporal variable to the rest of
pipeline. that also means that |foo> "remembers" the return values
_only_ from the thing on its _closest_ left .
then something like that can be made to work :
@source |> grep { ... }
|ok> map { ... } |> @foo,
|nok> map { ... } |> @bar ;
I am not sure this is a good solution
but I think that "purge" and L2R-R2L threads of this maillist have to
be more close somehow.
arcadi
Re: L2R/R2L syntax
On Tuesday, January 21, 2003, at 02:04 AM, Graham Barr wrote:
If the function form of map/grep were to be removed, which has been
suggested,
and the <~ form maps to methods. How would you go about defining a
utility
module similar to List::Util that uses the same syntax as map/grep but
without making the subs methods on the global ARRAY package ?
If you want the method to be available everywhere, you probably
_should_ make it a method of the global Array class. More typically,
perhaps, you'd only be using your new method to operate on certain
arrays that you use, in which case you would make a new class for those
particular arrays, so your new method would work only on the specific
arrays you intended it to:
class MyArray is Array {
method foo_grep (Code $test) returns MyArray {
...
}
}
my @a is MyArray = (1..10);
my @b = @a.foo_grep {...};
my @c = foo_grep {...} <~ @a; # identical
I don't see any problem (other than maybe a philosophical objection)
with making them methods of Array, though, if they're valuable enough.
That certainly would seem the common Perl thing to do.
MikeL
Re: Why C needs work (was Re: L2R/R2L syntax)
On Monday, January 20, 2003, at 04:33 PM, Michael Lazzaro wrote:
But both the OO and pipeline syntaxes do more to point out the noun,
verb, and adjective of the operation.
Adverb. The {...} part is an adverb, not an adjective. Sorry there.
MikeL
Re: L2R/R2L syntax
On Tue, Jan 21, 2003 at 09:20:04AM -0800, Michael Lazzaro wrote: > > On Tuesday, January 21, 2003, at 02:04 AM, Graham Barr wrote: > > If the function form of map/grep were to be removed, which has been > > suggested, > > and the <~ form maps to methods. How would you go about defining a > > utility > > module similar to List::Util that uses the same syntax as map/grep but > > without making the subs methods on the global ARRAY package ? > > If you want the method to be available everywhere, But I don't > you probably > _should_ make it a method of the global Array class. Thats like trying to wite a whole perl5 application in main without any packages > More typically, > perhaps, you'd only be using your new method to operate on certain > arrays that you use, in which case you would make a new class for those > particular arrays, so your new method would work only on the specific > arrays you intended it to: Thats not always possible. Those Arrays may be passed to me from somewhere else, so I have no control over thier class. > I don't see any problem (other than maybe a philosophical objection) > with making them methods of Array, though, if they're valuable enough. > That certainly would seem the common Perl thing to do. No, namespaces were invented for a reason. Graham.
Perltalk
Smylers [mailto:[EMAIL PROTECTED]] wrote:
> And an alternative
> spelling for the assignment operator[*0] doesn't strike me as something
> Perl is really missing:
>
> $msg <~ 'Hello there';
> $msg = 'Hello there';
I still remember the first time I saw a computer program, before I had
learned anything about programming myself. A friend showed me his first
Fortran program, and it included the following line:
N = N + 1
I stared at that in puzzlement for a long minute, and then said "That sure
isn't true for any value of N that *I* know of!" Then he told me that "="
doesn't mean "equals" in Fortran (no, *that's* spelled "EQ" :-).
I've always been bothered by this misuse of mathematical notation, which is
used in an incredibly bewildering array of computer programming languages.
On the other hand, I've never been a fan of the ":=" spelling of assignment,
either. I always thought that "<-" was much better, except for the pitfall
that humans are likely to misread "a<-5" as a comparison.
One of the most... er, *interesting*, dodges I've seen in this area is the
one used by Squeak (a Smalltalk variant). Squeak spells assignment with an
underscore ("_"), but the Squeak system *draws* it as a left-pointing arrow.
Hey, I know: let's not bother with Unicode...let's just reassign a few ASCII
control characters for Perl's use! :-)
I, for one, could live with "<~" as the only assignment operator. But I only
suggest it tongue in cheek.
Speaking of Squeak, I notice that Buddha Buck just posted a
Smalltalk-translated-to-Perl implementation of the if-operator:
> class True is Bool is singleton {
>...
> our True true is builtin;
>etc.
which even includes the notion that the implementation of True and False is
immutable, so that the code generator has a ghost of a chance of knowing
what to do!
That was followed by Austin Hastings' post:
> log $user onto $system.
> log $message to $stderr.
> l2x = log 2 * log $x; # Don't check my math, please. :-)
> ...
> sub log($n) { ... }
> sub log _ onto($user; &_ ; $machine) { ... }
> sub log _ to($message; &_ ; $stream) { ... }
which is a recycling of Smalltalk's "inject:into:"-style operators. I have
to admit that I *like* the idea of being able to define those kinds[1] of
operators; they can really add to the clarity of the code. I just don't want
to have to write the parser!
[1] What *do* you call this style of operator -- intermingled-fix?
Looks like we've got some Smalltalk fans here. What say we start a new
mailing list for designing Perltalk? :-)
=thom
Riker: "They were just sucked into space."
Data: "Blown, sir."
Riker: "Sorry, Data."
Data: "Common mistake, sir."
(The Naked Now)
RE: A proposal on if and else
Rafael Garcia-Suarez [mailto:[EMAIL PROTECTED]] wrote: > The tokeniser could send two tokens "else" and "if" whenever it > recognizes the keyword "elsif" -- so this isn't a problem. The primary advantage, to my mind, in using C, is that it eliminates the dangling-else ambiguity -- so splitting it in half removes almost ALL the value of even having an C keyword. =thom "More people worry themselves to death than bleed to death." -- _Tunnel_in_the_Sky_, Robert Heinlein
Re: Perltalk
On 2003-01-21 at 11:09:21, Thom Boyer wrote:
> One of the most... er, *interesting*, dodges I've seen in this area is the
> one used by Squeak (a Smalltalk variant). Squeak spells assignment with an
> underscore ("_"), but the Squeak system *draws* it as a left-pointing arrow.
There's a history behind that particular choice; before the ISO-8859
standardization, people got the characters they needed by making
"mostly-ASCII" character sets that differed in small ways from the
original US standard. Having a left-pointing arrow in place of the
underscore was a common variant (used in, for instance, PET ASCII
on Commodore computers, which also had other substitutions, such
as the letter pi in place of tilde, and the British pound symbol
in place of backslash).
Assignment has been written as a left arrow in pseudocode for
decades, but because the character was left out of ASCII (although
it's in EBCDIC), its use within actual languages has been pretty
much limited to those which already specify their own character set
and/or glyph display anyway (such as APL). I do know of at
least one Pascal derivative that uses '<-' as a synonym for ':=',
requiring whitespace if your intent is the relational operator followed
by unary minus.
Squeak does, incidentally, also let you use := for assignment, which is
the standard for ASCII Smalltalk.
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Perltalk
Thom Boyer wrote: > Smylers [mailto:[EMAIL PROTECTED]] wrote: > > > And an alternative spelling for the assignment operator[*0] doesn't > > strike me as something Perl is really missing: > > > > $msg <~ 'Hello there'; > > $msg = 'Hello there'; > > I still remember the first time I saw a computer program ...: > > N = N + 1 > > ... "That sure isn't true for any value of N that *I* know of!" ... > I've always been bothered by this misuse of mathematical notation, .. In this respect I was fortunate that the first language I saw was a Basic[*0] dialect which used C: LET n = n + 1 which avoids much of the confusion, at the annoyance of having to type a keyword for such a common operation. I at least slightly share your botheredness -- I found it distinctly odd when I first saw the C being dropped -- but try not to think about it most of the time, having just got accustomed to the "misuse". [*0] Please note I'm specifically _not_ commenting on how fortunate or otherwise that was in _other_ respects. > I always thought that "<-" was much better ... I, for one, could live > with "<~" as the only assignment operator. But I only suggest it > tongue in cheek. My first version of the message you quoted above had a footnote with exactly that tongue-in-cheek suggestion, saying that, as an alternative, if right-left streams are to be kept then could we drop C<=>. This has several plausible-sounding advantages, including the one you highlight, making assignment completely reversible (allowing statements which emphasize the value rather than the variable having equal status to the usual way round), and avoiding the common beginner confusion of trying to use C<=> to test for equality. But then I remembered assignent short-cut operators. $msg ~<~ "Your current balance is $total.\n"; Regardless of where your font puts the squiggles, I just don't see that looking like a concatenation operator ... Smylers
TPF donations (was Re: L2R/R2L syntax [x-adr][x-bayes])
On Fri, Jan 17, 2003 at 04:21:08PM -0800, Damian Conway wrote: > Paul Johnson wrote: > > > Well, I'll be pretty interested to discover what cause is deemed more > > deserving than Larry, Perl 6 or Parrot. The P still stands for Perl, > > right? > > True. But I suspect that TPF's position is that, to many people, Perl 6 is > far less important than mod_Perl, or DBI, or HTML::Mason, or POE, or PDL, or > Inline, or SpamAssassin, or XML::Parser, or YAML, or the Slashcode, or any of > a hundred other projects on which their job depends on a daily basis. > > Supporting those efforts is important too, and TPF has only limited resources. Correct me if I'm wrong, but isn't the one thing that all those projects have in common...well...Perl? And isn't Larry the guy to whom we owe the existence of Perl? I'm not fortunate enough to be using Perl in my job, but I'm still more than happy to pony up for a donation, purely from gratitude. This is something along the lines of the applied research vs basic research question. What Larry is doing pretty much amounts to basic research that will help all of these other projects in the long run. --Dks
Re: L2R/R2L syntax
Graham Barr <[EMAIL PROTECTED]> writes:
> On Mon, Jan 20, 2003 at 07:27:56PM -0700, Luke Palmer wrote:
>> > What benefit does C<< <~ >> bring to the language?
>>
>> Again, it provides not just a "null operator" between to calls, but
>> rather a rewrite of method call syntax. So:
>>
>> map {...} <~ grep {...} <~ @boing;
>>
>> is not:
>>
>> map {...} grep {...} @boing;
>>
>> But rather:
>>
>> @boing.map({...}).grep({...});
>
> This is not a for or against, but there is something that has been
> bugging me about this.
>
> Currently in Perl5 it is possible to create a sub that has map/grep-like
> syntax, take a look at List::Util
>
> If the function form of map/grep were to be removed, which has been
> suggested, and the <~ form maps to methods. How would you go about
> defining a utility module similar to List::Util that uses the same
> syntax as map/grep but without making the subs methods on the global
> ARRAY package ?
Well, I very much hope that the function form won't be going away;
functional style is bloody useful dammit and I don't want to be forced
to add line noise just to make those who have a woody for
orthogonality happy. Anyhoo, if it *does* go away, then it should be
possible to set up an appropriate set of multiply dispatched generic
functions.
sub reduce ( &block, $init, *@array ) is multi {
@array.reduce(&block, $init);
}
sub reduce ( &block, $init, Collection $collection ) is multi {
$collection.reduce(&block, $init);
}
sub reduce ( $expr is qr//,
$init, *@array ) is immediate, is multi {
@array.reduce( $expr, $init);
}
sub reduce ( $expr is qr/Perl::term/,
$init, Collection $collection ) is immediate, is multi
{
$collection.reduce($expr, $init);
}
Though I'm sure Damian will be long eventually to correct my
syntax. I'm getting this weird feeling of deja vu though...
--
Piers
Re: TPF donations
David Storrs <[EMAIL PROTECTED]> writes: > On Fri, Jan 17, 2003 at 04:21:08PM -0800, Damian Conway wrote: >> Paul Johnson wrote: >> >> > Well, I'll be pretty interested to discover what cause is deemed more >> > deserving than Larry, Perl 6 or Parrot. The P still stands for Perl, >> > right? >> >> True. But I suspect that TPF's position is that, to many people, >> Perl 6 is far less important than mod_Perl, or DBI, or HTML::Mason, >> or POE, or PDL, or Inline, or SpamAssassin, or XML::Parser, or >> YAML, or the Slashcode, or any of a hundred other projects on which >> their job depends on a daily basis. >> >> Supporting those efforts is important too, and TPF has only limited >> resources. > > Correct me if I'm wrong, but isn't the one thing that all those > projects have in common...well...Perl? And isn't Larry the guy to > whom we owe the existence of Perl? I'm not fortunate enough to be > using Perl in my job, but I'm still more than happy to pony up for a > donation, purely from gratitude. > > This is something along the lines of the applied research vs basic > research question. What Larry is doing pretty much amounts to basic > research that will help all of these other projects in the long run. I shall certainly be thinking long and hard about passing the perl.com payments to TPF if Larry's not being funded this year (if I should become a member of the copious free time club there'll be no thought necessary I'm afraid, income is income). Which reminds me, I need to check (as I have naively assumed) that the money is automagically being paid to TPF without my having to muck about with invoices and the like. Hmm... Seriously, I think that not putting some funding Larry's way is a big mistake. I'm not saying he should be the only recipient of funds, but he *is* a special case.
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
On Tuesday, January 21, 2003, at 12:26 PM, Piers Cawley wrote: Though I'm sure Damian will be long eventually to correct my syntax. I'm getting this weird feeling of deja vu though... When I come home from work each day, I can see my dog eagerly waiting at the window, just black snout and frenetically wagging tail visible over the sill. I often think Larry and Damian must feel that way about this group. Poor, comical beasts, but so eager and well-meaning. We greet them so enthusiastically when they've arrived, it's hard for them to get too mad at us. Even when they discover we've peed on the carpet while they've been gone, and they have an awful mess to clean up. MikeL
"Arc: An Unfinished Dialect of Lisp"
I just finished skimming this write-up, located at http://paulgraham.com/arcll1.html I'm not a Lisp enthusiast, by and large, but I think he makes some interesting observations on language design. Take a look if you're feeling adventurous... -r -- email: [EMAIL PROTECTED]; phone: +1 650-873-7841 http://www.cfcl.com/rdm- my home page, resume, etc. http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection
Re: L2R/R2L syntax
Michael Lazzaro <[EMAIL PROTECTED]> writes: > On Tuesday, January 21, 2003, at 12:26 PM, Piers Cawley wrote: >> Though I'm sure Damian will be long eventually to correct my >> syntax. I'm getting this weird feeling of deja vu though... > > When I come home from work each day, I can see my dog eagerly waiting > at the window, just black snout and frenetically wagging tail visible > over the sill. > > I often think Larry and Damian must feel that way about this group. > Poor, comical beasts, but so eager and well-meaning. We greet them so > enthusiastically when they've arrived, it's hard for them to get too > mad at us. Even when they discover we've peed on the carpet while > they've been gone, and they have an awful mess to clean up. Heh. I wouldn't mind, but I'm getting the very strong feeling that this is about the third time we've returned to this particular pile of vomit and spread it around differently. Everyone, please don't take that perjoratively, I just saw the opportunity to extend Mike's metaphor further than it should be expected to go, and I took it. Right, back to the summary. -- Piers
Re: Why C needs work (was Re: L2R/R2L syntax)
Michael Lazzaro wrote:
> On Monday, January 20, 2003, at 12:30 PM, Smylers wrote:
>
> > It was only on reading that (and discovering that you hadn't
> > previously known about the 'optional comma with closure argument'
> > rule) that I understood why you had previously been so in favour of
> > proposed new syntaxes: through a desire to banish the Perl 5 syntax.
>
> Yes. Again, it's not that I never knew about the perl5 rule,
Sorry, I wasn't meaning to suggest that you didn't know Perl 5; I was
specifically referring to your saying that you'd presumed that
conditions and loops were special cases in the grammar, but that
actually they'll be dealt with by the general Perl _6_ rule about commas
and closure arguments.
> it's that I _dislike_ the perl5 rule, ...
Oh. That's "dislike" rather than "disliked"? My question was
predicated on your declaration "I emphatically withdraw my objection",
which I took to mean that your knowledge of the infrared comma rule --
or whatever it's called -- meant you no longer disliked the Perl 5
syntax?
> as I dislike most special-case grammar rules.
So do I! I was particularly impressed by the ultraviolet comma rule,
and how it avoids special cases, when Damian paraded it at a talk last
summer.
I also don't reckon it's _that_ special. So long as the rule is that
such commas are optional, as distinct from their absence being
mandatory, then the rule is a very general one: commas may be omitted
where they aren't needed to delimit list items. Obviously with string
and numeric values commas are always required:
$a -1
They are the only way of determining op/term for the minus sign: a
single argument of one less than the value in C<$a>, or two arguments
with the second being minus one?
But closures can be unambiguously determined without commas. Since
whitespace is no longer allowed in hash look-ups, space followed by an
open brace must be the start of a closure, and hence another argument.
Similarly once the closing brace has been reached the closure is ...
ahem, closed, so anything following must be a separate argument.
> If we dropped C, etc., we could drop the inferred-comma rule as
> well (unless we're really successful in making C a simple
> function, in which case we need the rule anyway, so who cares?)
I guess that's the crucial issue. Since it was Damian saying that it is
possible to have C and friends as functions -- and since this was
something that'd already been dealt with before I joined this list, and
so presumably would've had any impossibility pointed out -- I believed
it to be true.
There's another sub-thread casting doubt on -- and trying to resolve --
the issue. I completely agree that whether the infrared comma rule is
needed over there makes a big difference to its use here.
But I think I disagree about the "who cares" part ...
> But the inferred-comma rule is tangential to my dislike of the current
> C syntax. I'd dislike C, and like pipelines, even if the
> inferred-comma rule wasn't there.
As you've not doubt noticed, I'm the opposite: I like C and don't
(yet?) see the point of right-left pipelines. (That means not that I
claim you're in some way 'wrong' to have those preferences, merely that
we think differently to each other.) There's one Perl slogan that'd
suggest having both ways in the language, so both of us get to code in
the way we like.
Countering that is the risk of adding too many ways of doing things and
just causing confusion for everybody with all the different ways of
invoking functions/methods on data. Hence my quibble with "who cares":
I could probably be persuaded that it's 'better' for the language not to
have the Perl 5 syntax, my preference, than to have so many alternative
syntaxes. (I'm not sure.)
> > Mike ... do you still find right-left pipelines as compelling as
> > you've previously argued?
>
> Yes, very much so. ... I've seen quite a few newbies struggle with
> the C syntax;
Me too. The most-strugglable bit for many has been the right-left data
flow, that you start by typing where you want the data to end up, then
the process it goes through last, then the process it goes through
first, and lastly the data that's being processed. Left-right pipelines
should be great at fixing this.
> the most frequent mistake is to reverse the order of the arguments,
> saying
>
> map @a, {...}
That happens if you conceptualize C as taking two arguments. In my
mind C operates on items in a list (and it just so happens that
in Perl an array provides a list):
map { ... } $a, $b, $c;
So C takes _many_ arguments, and one of these arguments is not like
the others. And it makes sense to put the 'special' argument first.
(That's also how I remember which way round things like C are.)
Thinking of it as operating on a list of things also helps to emphasize
that C processes just a single item at a time, that it isn't an
agregate operation on the items as a group.
> (Another common one is to not understa
Re: A proposal on if and else
Thom Boyer wrote:
> The primary advantage, to my mind, in using C, is that it
> eliminates the dangling-else ambiguity -- so splitting it in half
> removes almost ALL the value of even having an C keyword.
Surely it's the compulsory braces, even with a single statement, which
eliminates that problem?
These look ambiguous to me, with no C required:
if test1
if test2
statement_A;
else
statement_B;
if test1
if test2
statement_A;
else
statement_B;
Where as putting the braces in there always disambiguates which C
and C goes with:
if test1 {
if test2 {
statement_A;
}
else {
statement_B;
}
}
if test1 {
if test2 {
statement_A;
}
}
else
{
statement_B;
}
Smylers
Re: Re: TPF donations
This is a valuable discussion, and I hope people will take this up on [EMAIL PROTECTED] as well. Thanks, John A see me fulminate at http://www.jzip.org/
Re: Perltalk
--- Thom Boyer <[EMAIL PROTECTED]> wrote:
> Smylers [mailto:[EMAIL PROTECTED]] wrote:
>
> > And an alternative
> > spelling for the assignment operator[*0] doesn't strike me as
> something
> > Perl is really missing:
> >
> > $msg <~ 'Hello there';
> > $msg = 'Hello there';
>
>
> I still remember the first time I saw a computer program, before I
> had
> learned anything about programming myself. A friend showed me his
> first
> Fortran program, and it included the following line:
>
> N = N + 1
>
> I stared at that in puzzlement for a long minute, and then said "That
> sure
> isn't true for any value of N that *I* know of!" Then he told me that
> "="
> doesn't mean "equals" in Fortran (no, *that's* spelled "EQ" :-).
>
> I've always been bothered by this misuse of mathematical notation,
> which is
> used in an incredibly bewildering array of computer programming
> languages.
> On the other hand, I've never been a fan of the ":=" spelling of
> assignment,
> either. I always thought that "<-" was much better, except for the
> pitfall
> that humans are likely to misread "a<-5" as a comparison.
>
> One of the most... er, *interesting*, dodges I've seen in this area
> is the
> one used by Squeak (a Smalltalk variant). Squeak spells assignment
> with an
> underscore ("_"), but the Squeak system *draws* it as a left-pointing
> arrow.
> Hey, I know: let's not bother with Unicode...let's just reassign a
> few ASCII
> control characters for Perl's use! :-)
>
> I, for one, could live with "<~" as the only assignment operator. But
> I only
> suggest it tongue in cheek.
>
Hey! Don't make me come over there...
>
>
> Speaking of Squeak, I notice that Buddha Buck just posted a
> Smalltalk-translated-to-Perl implementation of the if-operator:
> > class True is Bool is singleton {
> >...
> > our True true is builtin;
> >etc.
>
> which even includes the notion that the implementation of True and
> False is
> immutable, so that the code generator has a ghost of a chance of
> knowing
> what to do!
>
> That was followed by Austin Hastings' post:
>
> > log $user onto $system.
> > log $message to $stderr.
> > l2x = log 2 * log $x; # Don't check my math, please. :-)
> > ...
> > sub log($n) { ... }
> > sub log _ onto($user; &_ ; $machine) { ... }
> > sub log _ to($message; &_ ; $stream) { ... }
>
> which is a recycling of Smalltalk's "inject:into:"-style operators. I
> have
> to admit that I *like* the idea of being able to define those
> kinds[1] of
> operators; they can really add to the clarity of the code. I just
> don't want
> to have to write the parser!
> [1] What *do* you call this style of operator -- intermingled-fix?
>
> Looks like we've got some Smalltalk fans here. What say we start a
> new
> mailing list for designing Perltalk? :-)
I can't even smell Spalltalk.
=Austin
Re: TPF donations (was Re: L2R/R2L syntax [x-adr][x-bayes])
--- David Storrs <[EMAIL PROTECTED]> wrote: > On Fri, Jan 17, 2003 at 04:21:08PM -0800, Damian Conway wrote: > > Paul Johnson wrote: > > > > > Well, I'll be pretty interested to discover what cause is deemed > more > > > deserving than Larry, Perl 6 or Parrot. The P still stands for > Perl, > > > right? > > > > True. But I suspect that TPF's position is that, to many people, > Perl 6 is > > far less important than mod_Perl, or DBI, or HTML::Mason, or POE, > or PDL, or > > Inline, or SpamAssassin, or XML::Parser, or YAML, or the Slashcode, > or any of > > a hundred other projects on which their job depends on a daily > basis. > > > > Supporting those efforts is important too, and TPF has only limited > resources. > > Correct me if I'm wrong, but isn't the one thing that all those > projects have in common...well...Perl? And isn't Larry the guy to > whom we owe the existence of Perl? I'm not fortunate enough to be > using Perl in my job, but I'm still more than happy to pony up for a > donation, purely from gratitude. > > This is something along the lines of the applied research vs basic > research question. What Larry is doing pretty much amounts to basic > research that will help all of these other projects in the long run. Sure. But managing the funding budget isn't a business, where basic research will enable more income. It's the allocation of scarce resources. And from that viewpoint, Larry and P6 is an iceberg, just cruising along hoping to gash a massive hole in the support/maintenance schedule, because once P6 rolls all the other stuff has to be sorted, ported, and supported. If I was in charge of the TPF funding budget, I'd be yearning to pick up the phone whenever I saw an episode of "The Sopranos"(*)... =Austin
Re: Why C needs work (was Re: L2R/R2L syntax)
On Tuesday, January 21, 2003, at 01:31 PM, Smylers wrote:
Michael Lazzaro wrote:
it's that I _dislike_ the perl5 rule, ...
Oh. That's "dislike" rather than "disliked"? My question was
predicated on your declaration "I emphatically withdraw my objection",
which I took to mean that your knowledge of the infrared comma rule --
or whatever it's called -- meant you no longer disliked the Perl 5
syntax?
I still dislike it, but if a variation upon it means we can make things
like C, C, etc. semi-normal functions, instead of cases within
the grammar, then I think everyone agrees that would be a Good Thing.
Keeping one grammar special case in return for not having a dozen
others -- yeah, I'll sign up for that.
I don't loath the old C syntax to the point where I'd just die if
it were there. And I don't expect we'd really get rid of it, it's too
intrinsic to Perl5. At very minimum, we'd have to keep the global
functions around as a module you could load for Perl5-friendliness.
I do think OO & pipelines are the better, more generic way to do the
same thing. So I'd really like to see pipelines, even if they're just
in addition to the old C style. After that, it's just a question
of whether the old style is worth the redundant declarations, which is
purely a matter-of-taste thing.
the most frequent mistake is to reverse the order of the arguments,
saying
map @a, {...}
That happens if you conceptualize C as taking two arguments.
I think you're right about that. And we have both:
for (@a) {...}
and
map {...} @a;
Which stings some newbies repeatedly, poor lads.
Was that an understandable explanation? :-)
Yes. Thanks, again. Please don't take personally my disagreeing with
so much you've written!
On the contrary. I'm just so happy someone understood what I was
trying to say, I think I'm going to burst into tears... Wait, no...
OK, I'm better now.
MikeL
Re: Why C needs work (was Re: L2R/R2L syntax)
Smylers wrote: Michael Lazzaro wrote: And it provides a very visual way to define any pipe-like algorithm, in either direction: $in -> lex -> parse -> codify -> optimize -> $out; # L2R $out <- optimize <- codify <- parse <- lex <- $in; # R2L It's clear, from looking at either of those, that they represent data pipes. Yes; that is nice. I'm just not convinced that it's sufficiently nice to require adding yet another way of passing data around to the language. I'm happy enough with the asymmetry that occurs just having the arrows to indicate 'reverse flow' data. The problem with this example is that the two lines deal with two different calling conventions, going by Damian's proposal... Perl 5 has two different code calling conventions: object oriented method calls, and procedural subroutine calls. OO method calls are L2R already: $object.method1().method2().method3().method4(); Procedural subroutine calls are R2L already: sub4 sub3 sub2 sub1 $variable; But there is no way to do OO method calls R2L, and there is no way to do procedural subroutine calls L2R. Damian's ~> and <~ proposal fills in this gap: method4 <~ method3 <~ method2 <~ method1 <~ $Xbject; $variable ~> sub1 ~> sub2 ~> sub3 ~> sub4; To the best of my knowledge, the following two WILL NOT WORK: sub4 <~ sub3 <~ sub2 <~ sub1 <~ $variable; $Xbject ~> method1 ~> method2 ~> method3 ~> method4 The first one tries to invoke the sub1 method of $variable, while the second tries to call the method1 function with $object as an argument. If either of these works, it's either coincidence or careful planning. So the apparant symmetry between <~ and ~> isn't really there. I like <~ and ~>, but I think that it will be a common mistake to think that $a ~> b~>c~>d can be reversed to give d<~c~, at least as currently formulated.
Re: Why C needs work (was Re: L2R/R2L syntax)
On Tuesday, January 21, 2003, at 02:38 PM, Buddha Buck wrote: Michael Lazzaro wrote: And it provides a very visual way to define any pipe-like algorithm, in either direction: $in -> lex -> parse -> codify -> optimize -> $out; # L2R $out <- optimize <- codify <- parse <- lex <- $in; # R2L It's clear, from looking at either of those, that they represent data pipes. The problem with this example is that the two lines deal with two different calling conventions, going by Damian's proposal... So the apparant symmetry between <~ and ~> isn't really there. I like <~ and ~>, but I think that it will be a common mistake to think that $a ~> b~>c~>d can be reversed to give d<~c~, at least as currently formulated. Agreed, it could be quite misleading. Personally, I'd be happier if <~ and ~> worked _only_ on objects and methods, instead of arbitrary subs... but I understand the utility of the other way. Of course, _I'd_ even prefer using <- and -> as the 'piping' operators, and having ~> or |> for pointy sub, because then $a->foo and $a.foo really _could_ be the same thing, 'cept for precedence. But that's not gonna happen, and _I'm_ not gonna press it. :-) MikeL
Re: Perltalk
> "MJR" == Mark J Reed <[EMAIL PROTECTED]> writes:
MJR> On 2003-01-21 at 11:09:21, Thom Boyer wrote:
>> One of the most... er, *interesting*, dodges I've seen in this area
>> is the one used by Squeak (a Smalltalk variant). Squeak spells
>> assignment with an underscore ("_"), but the Squeak system *draws*
>> it as a left-pointing arrow.
MJR> There's a history behind that particular choice; before the ISO-8859
MJR> standardization, people got the characters they needed by making
MJR> "mostly-ASCII" character sets that differed in small ways from the
MJR> original US standard. Having a left-pointing arrow in place of the
MJR> underscore was a common variant (used in, for instance, PET ASCII
MJR> on Commodore computers, which also had other substitutions, such
MJR> as the letter pi in place of tilde, and the British pound symbol
MJR> in place of backslash).
<- instead of underscore goes way back. the teletype (ASR33 and friends)
had <- on the keyboard and the print head.
MJR> Assignment has been written as a left arrow in pseudocode for
MJR> decades, but because the character was left out of ASCII (although
MJR> it's in EBCDIC), its use within actual languages has been pretty
it wasn't left out but the graphic morphed to underscore sometime in the
70's. the vt52, decterminals and such came out then and had underscore
instead of <-. the ascii code stayed the same.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: TPF donations (was Re: L2R/R2L syntax [x-adr][x-bayes])
On Tue, Jan 21, 2003 at 02:21:58PM -0800, Austin Hastings wrote: > > --- David Storrs <[EMAIL PROTECTED]> wrote: > > This is something along the lines of the applied research vs basic > > research question. What Larry is doing pretty much amounts to basic > > research that will help all of these other projects in the long run. > > Sure. But managing the funding budget isn't a business, where basic > research will enable more income. It's the allocation of scarce I'm not convinced that that is correct. Basic research may enable more income. If it works. But at least 90% of basic research won't. Hence you have to do a lot of it, but the odd time you get it right, it can be very lucrative > resources. And from that viewpoint, Larry and P6 is an iceberg, just > cruising along hoping to gash a massive hole in the support/maintenance > schedule, because once P6 rolls all the other stuff has to be sorted, > ported, and supported. I'm not quite following you - this looks like an argument against P6, because its appearance will create a lot more work? > If I was in charge of the TPF funding budget, I'd be yearning to pick > up the phone whenever I saw an episode of "The Sopranos"(*)... And this I don't follow at all, having never seen The Sopranos. So I'm probably completely failing to address the points you are making The problem I see with not funding Larry, is that if as a consequence Larry has to get a job that prevents him from working on Perl 6, Perl 6 won't happen until he retires. Anyone can implement Perl 6 (although I reckon we'd have a setback of many months on parrot if Dan stopped and left, and more if other people dropped out as a result. But it can be picked up by anyone capable). Not just anyone can design Perl 6. The obvious counter argument is that if Perl 6 stops, Perl 5 as is won't go away; Perl 5 is what we have; Perl 5 is what we are using, and Perl 5 is good enough. However eventually everyone volunteering to work on it will drift away. At which point it is stagnant, and no bugs get fixed. For some reason, Perl 6 actually brought a lot of new blood and new momentum to Perl 5. I suspect Perl 5.8 would not have happened, or at least not have happened yet, had Perl 6 not been around. Perl 6 may seem crazy, far fetched and long term. Yet it is bringing morale to Perl 5, suggesting that Perl does have a future, and that maybe Perl 5 is worth working on. If Perl 5 doesn't feel worth working on, then most will go away. I've been involved in development communities before where the future has been pulled out from under our feet. The community dissipates - there is more fun to be had elsewhere. You may think that volunteers on Perl 5 are not important. You may not be using Perl 5.8, and you may see no need to. Ever. But if you're using 5.004, 5.005_03 or 5.6.1, and you have hit a bug in it, how are you going to get it fixed? Currently bugs discovered in 5.8 are actively being fixed (or at least ought to be - nag p5p if they aren't). But a release of 5.6.2 looks unlikely, and 5.005_04 equally improbable. How would you feel if there was never going to be a 5.8.1 either? Would it affect your technology choice? Would it affect your clients'/employers'? Hence I would argue that if Perl 6 halts, Perl 5 stops looking credible long term. Which I don't want to happen. Currently this argument is shaky, because to an external observer, Larry with funding unable to produce apocolypses due to other reasons is indistinguishable from Larry unable to produce apocolypses due to lack of funding. Except that there is visibly less money for anything else worthy. Nicholas Clark
