Re: Arc: An Unfinished Dialect of Lisp
On Tue, Jan 21, 2003 at 12:55:56PM -0800, Rich Morin wrote: 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... I can't help feeling slightly deflated. Given the chance to re-design Lisp from scratch, the tasks on the top of my TODO list to address would be: * getting rid of some/all those damn parenthesis * renaming cons/car/cdr to something meaningful Alas, these are about the only parts he's not changing. He promises that Arc will have a syntax one day, but there isn't one yet. The other comments that caught my eye were that Arc is designed for Good Programmers[tm] and that it was particularly targetted at developing web applications. Alas, my experience seems to suggest that most of the people writing web applications are monkeys who would rather have something designed for Bad Programmers, like PHP. A
Re: L2R/R2L syntax
Damian Conway writes:
Not equivalent at all. C$foo~bar means append $foo to the argument list
of subroutine Cbar. Cfoo.bar means make C$foo the invocant for method
bar.
Curiously enough, the confusions I'm hearing over this issue are, to me, the
strongest argument yet for using Andy's | and | symbols instead.
Damian
Proposal :( but may be this is just part of the above mentioned
confusion:)
* we probably should distinguish between
+ pseudo-pipes ( I spell them as : and : )
+ and right- and left- assignment operators ( I
spell them ... = $var and $var = ... ) .
these should be aware of distinction between assignment and
binding -- so probably there have to be 2 forms of each ???
* : and : should be thought of ( and probably actually are ) just
( special ) __commas__ in the following sense :
@a : sort { ... }#== sort { ... } @a:
@a : join ... #== join ... @a:
sort { ... } : @a #== sort { ... } @a:
join ... : @a #== join ... @a:
so it seems that ( already discussed ) redunduncy of : can be solved
by saying that
* : is doing to the _following_ term _the_same_thing_ ( makes it an
adverb ) as what : is doing to the _preceding_ term --- so : is sort
of prefix form special comma : .
that means that : is prefix adverbial comma - and the verb is
to be found _before_ the : comma .
* : is different . it makes the _preceding_ term an adverb --- but
the corresponding verb have to be searched _after_ the : comma .
it seems that all the distinction between methods and subroutines is
now handled if methods and subroutines know how to handle adverbial
arguments. ( but this does not allow to place _usual_ arguments
before the subroutine/method -- so probably there have to be another
comma )
It seams that with this in mind and usual precedence rules we can
make multimethods enjoy the l2r notations.
( $square : init ) :
( $circle : init ) : do_something
do_something : ($square : init)
: ($circle : init)
arcadi
Re: Why Cmap needs work (was Re: L2R/R2L syntax)
Michael Lazzaro [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
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. :-)
I wouldn't (and don't) give up so easily! The - syntax for anonymous
subs is cute: but it seems to be cute only in limited contexts -- those
where it is also being used as a (conceptual) piping operator.
Compare:
$a = sub ($a, $b) { ... }
$x = - ($y, $z) { ... }
The pointy-arrow doesn't buy anything here.
But in a for loop:
for 1,2,3,4 { ... }
for 1,2,3,4 - ($a,$b) {...}
its cuteness works because the brain sees it as a piping operator (even
though its not).
Perl6 is still Perl. We're allowed to do a bit of DWIMery in the parser,
if needed, to make the simple (common) cases work. So perhaps we
should define the Cfor in terms of pipelines. With some minor
syntax changes, we can free up the - operator:
for 1,2,3,4 ~ sub ($a,$b) { ... }
Sure, its not quite so cute. You could rename the Csub if desired
(for example, perhaps it could be spelt Cmy in this context, though
you'd need to work on the lexical scoping rules). The only remaining
magic would be to retrofit the basic Cfor to work.
And then we can replace the ~ with -:
for 1,2,3,4
- sub ($a, $b) { $a+$b }
- sub ($a) { $a**2 }
- { $^foo - 1 }
- print;
And this begs the question: what exactly does the Cfor contribute to
the semantics of the pipeline? What would Cmap (in void context)
do differently?
Dave.
Re: A proposal on if and else
Smylers wrote:
Thom Boyer wrote:
The primary advantage, to my mind, in using Celsif, is that it
eliminates the dangling-else ambiguity -- so splitting it in half
removes almost ALL the value of even having an Celsif keyword.
Surely it's the compulsory braces, even with a single statement, which
eliminates that problem?
Almost. The compulsory-braces rule [a Perl 5 syntax decision I applaud]
means that
if test1 {
statement_A;
} elsif test2 {
statement_B;
} elsif test3 {
statement_C;
}
is equivalent in meaning to
if test1 {
statement_A;
} else {
if test2 {
statement_B;
} else {
if test3 {
statement_C;
}
}
}
So if elsif becomes else followed by if in the scanner, the result
is syntactically wrong _because_ the curly braces are required (a point
that I missed in my earlier post):
if test1 {
statement_A;
} else if test2 { # syntax error: missing open brace after 'else'
statement_B;
} else if test3 { # Oops, I did it again
statement_C;
}
And let's not anybody say, Well, 'elsif' gets converted to 'else'
followed by '{' followed by 'if', then!, because that doesn't work. All
the closing right curly braces would still be missing.
So the compulsory curly braces make for a much more convincing argument
against an elsif -- else if conversion in the scanner.
Personally, I don't think anybody should be working this hard to make
if/elsif/elsunless/else writeable as a subroutine. I don't think it
should be put in that pigeonhole: it doesn't fit there very well.
If we really need the comfort of knowing that if/else/etc. is writable
in Perl 6, then we can all take comfort that it _is_ always possible (if
not as convenient) using the much more general grammar-extension mechanism.
=thom
Re: Why Cmap needs work (was Re: L2R/R2L syntax)
On Tue, Jan 21, 2003 at 03:52:30PM -0800, Dave Whipp wrote:
$a = sub ($a, $b) { ... }
$x = - ($y, $z) { ... }
The pointy-arrow doesn't buy anything here.
IMHO, it's actually a loss. I have yet to come up with any mnemonic
for pointy arrow means sub that will actually stick in my brain.
Every time I see this construct, I have to stop in my tracks and
mentally flip through the reference manual.
But in a for loop:
for 1,2,3,4 { ... }
for 1,2,3,4 - ($a,$b) {...}
its cuteness works because the brain sees it as a piping operator (even
though its not).
Agreed.
[snip]
And then we can replace the ~ with -:
for 1,2,3,4
- sub ($a, $b) { $a+$b }
- sub ($a) { $a**2 }
- { $^foo - 1 }
- print;
And this begs the question: what exactly does the Cfor contribute to
the semantics of the pipeline? What would Cmap (in void context)
do differently?
One potential answer: make 'map' be lazy by default and 'for' be
nonlazy (energetic? active? ADHD?). My logic in suggesting it this
way around is that, to me, 'for' seems to operate more on a whole
list, while 'map' is intended to operate on elements one after
another. Like so:
for (1,2,3) { print } # I want to call print for this whole list
map { print } (1,2,3) # Map the 'print' function over the elements
# of this list
--Dks
Lexically scoped methods (was: L2R/R2L syntax)
The question is, can I create a method on a class with a different scope than
the class itself has? Put another way, it seems like
module ArrayMath;
sub sum(Array $this){
$this.reduce(operator::+, 0);
}
method Array::sum(;){
.reduce(operator::+, 0);
}
(modulo syntax errors) then both should have the same visibility (ie, module
level only, unless they're somehow exported (what's that in perl6, is
public?)). So the question of namespace becomes moot, because just because
it's a method on Array doesn't mean it's accessible anywhere a similar sub
wouldn't be. Either could be exported and made globally available, but I don't
see why they should have to be. Or am I missing something?
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.
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
All of our customer service representatives are on vacation. Please hold for
the next available representative.
Re: Arc: An Unfinished Dialect of Lisp
--- Andy Wardley [EMAIL PROTECTED] wrote:
On Tue, Jan 21, 2003 at 12:55:56PM -0800, Rich Morin wrote:
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...
I can't help feeling slightly deflated. Given the chance to
re-design
Lisp from scratch, the tasks on the top of my TODO list to address
would
be:
* getting rid of some/all those damn parenthesis
* renaming cons/car/cdr to something meaningful
Actually, sanifying some of the syntax did have the effect of removing
some parens. The other parens are necessary to part of the philosophy
of the language: code is data, too.
Alas, these are about the only parts he's not changing. He promises
that
Arc will have a syntax one day, but there isn't one yet.
I think that's probably a joke. Lisp was originally promised a syntax,
and I'm doing a flavor of lisp. If it ever shows up, I'll do it, too.
The other comments that caught my eye were that Arc is designed for
Good Programmers[tm] and that it was particularly targetted at
developing
web applications. Alas, my experience seems to suggest that most of
the people writing web applications are monkeys who would rather have
something designed for Bad Programmers, like PHP.
You know, I learned pascal, PETbasic, then PL/I; PICK {basic/asm}, then
Prolog. Then I waited a bit, and learned Perl, at least enough to get
confused a lot on this list.
I'm done with 'P'. That's it. Putative planners of programming
paradigms must proffer some prefix preferable to the pathetic
palimpsest that is 'P'!
=Austin
Re: Arc: An Unfinished Dialect of Lisp
On Wed, 22 Jan 2003, Austin Hastings wrote: I'm done with 'P'. That's it. Putative planners of programming paradigms must proffer some prefix preferable to the pathetic palimpsest that is 'P'! As with operators, so with programming languages -- Unicode comes not a moment too soon. /s
Re: Why Cmap needs work (was Re: L2R/R2L syntax)
David Storrs [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
And then we can replace the ~ with -:
for 1,2,3,4
- sub ($a, $b) { $a+$b }
- sub ($a) { $a**2 }
- { $^foo - 1 }
- print;
And this begs the question: what exactly does the Cfor contribute to
the semantics of the pipeline? What would Cmap (in void context)
do differently?
One potential answer: make 'map' be lazy by default and 'for' be
nonlazy (energetic? active? ADHD?). My logic in suggesting it this
way around is that, to me, 'for' seems to operate more on a whole
list, while 'map' is intended to operate on elements one after
another. Like so:
for (1,2,3) { print } # I want to call print for this whole list
map { print } (1,2,3) # Map the 'print' function over the elements
# of this list
I have a feeling its the other way round:
(1,2,3,4) ~ map { print }
Vs
for 1,2,3,4 - print
The obj ~ method args form calls the method on the object. Cmap
is then a method (called on the entire list) that calls its codeblock for
each member
The for list - sub would call the sub for each member of the list. Hence
an equivalence:
for list - { per-elem code }
eq
list ~ map { per-elem code }
But remember, this is all getting very hypothetical: - doesn't (currently)
mean L2R pipe into sub
Dave.
Re: Why Cmap needs work (was Re: L2R/R2L syntax)
On Tuesday, January 21, 2003, at 03:52 PM, Dave Whipp wrote:
But in a for loop:
for 1,2,3,4 { ... }
for 1,2,3,4 - ($a,$b) {...}
its cuteness works because the brain sees it as a piping operator (even
though its not).
That's an excellent observation. I like the 'for' syntax quite a bit,
but never quite could put my finger on why it worked so well. You're
right, that's exactly it.
And this begs the question: what exactly does the Cfor contribute to
the semantics of the pipeline? What would Cmap (in void context)
do differently?
Hmm. Perhaps there doesn't _need_ to be a difference. You currently
use Cfor when you don't care about capturing the results. You use
Cmap when you do. But since we can identify context, perhaps they
could be synonyms, if we tweak things a little.
*** SPECULATION AHEAD ***
Note that Cfor allows you to name the arguments, using the pointy sub
rule:
for @a - ($a,$b) {...}
but note ALSO that it'd be great if Cmap and friends had that
capability, so you could Cmap two-at-a-time, etc. (Cgrep and
Csort don't really need it, but I *suppose* you could use it for
grepping/sorting tuples.)
So we want the pointy-sub rule for Cmap and friends too:
my @a = map - ($a,$b) {...}; # pass to {...} 2-at-a-time, as $a
and $b
Pretty neat.
But ignoring pointy-sub for the moment, and assuming that we in fact
used - and - to mean pre/post-invocant (e.g. pipes): if we defined
Cfor as just another word for Cmap, what we really want is rules
such that *all* of the following work. Question is, is it possible to
come up with something consistent. Maybe.
# void context
@a.map {...}
@a.for {...} # identical
@a - map {...} # identical
@a - for {...} # identical
@a - {...} # identical (a cool shorthand when given
a closure?)
for @a {...} # Doh! This wouldn't work
for @a : {...}# Hey, but this would (indirect object
syntax)
map @a : {...}# identical
for @a,@b,@c : {...} # is this OK?
for (@a,@b,@c) : {...}# OK, and better looking
# list context
my @a = @b - for {...}
my @a = @b - map {...} # identical
my @a = map {...} - @b # identical
my @a = for {...} - @b # identical
my @a - map {...} - @b# identical
my @a - for {...} - @b# identical
That works. Pretty darn well, too. (Note the critical bit, the
introduction of indirect object syntax to Cfor.)
*Now*, what to do about the fantastic magic that pointy-sub provides?
The _spectacular_ win would be if we could just recognize an optional
parameter list as part of a block.
map @a : ($a,$b) {...} # params + closure = closure with params?
for @a : ($a,$b) {...}
So that anywhere you had a closure, you could put a paramlist in front
of it. Not likely we could get that to work, since best-case scenario
it would probably barf on $a and $b being undefined before it ever got
to the closure. But it might be possible, at the expense of some
parser complexity.
If we couldn't do that, you would have to say:
for @a : sub ($a,$b) {...} # OK
or
@a - for sub ($a,$b) {...} # a bit icky
The first of those looks better than the second. I loathed the second
after I first wrote it, but now it's beginning to grow on me a bit
better. The intent is certainly clear, for example.
The pointy-sub syntax doesn't really work in these cases, though. I
can't think of anything you could use in place of 'sub' that would make
either of those look better.
So, the benefits of trying to pursue this: It makes Cfor and Cmap
synonyms, and gives each the magical powers of the other. The fact
even Cfor is now an object method means you could say:
for @obj : {...}
and even overload the Cfor behavior for a Collection-based @obj. It
also gets rid of the perl5 bugaboo:
for (@a) {...}
map {...} @a;# params are reversed. Newbie trap!
So the biggest single trick is, Cfor would have the colon after the
list:
for @a : {...}
If we did that, the rest might just work.
Anyway, just speculation.
MikeL
Re: Lexically scoped methods (was: L2R/R2L syntax)
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Cc: [EMAIL PROTECTED]
Date: Wed, 22 Jan 2003 09:03:13 -0600
From: Adam D. Lopresto [EMAIL PROTECTED]
X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
The question is, can I create a method on a class with a different scope than
the class itself has? Put another way, it seems like
module ArrayMath;
sub sum(Array $this){
$this.reduce(operator::+, 0);
}
method Array::sum(;){
.reduce(operator::+, 0);
}
(modulo syntax errors) then both should have the same visibility
(ie, module level only, unless they're somehow exported (what's that
in perl6, is public?)). So the question of namespace becomes
moot, because just because it's a method on Array doesn't mean it's
accessible anywhere a similar sub wouldn't be. Either could be
exported and made globally available, but I don't see why they
should have to be. Or am I missing something?
If I was designing the object system (something I have _so_ much
experience with :-P ), I'd say that you can't declare methods outside
of their class definition, but you can define subs that take that
class in the indirect object position.
sub sum(Array $this:) {
$this.reduce( { $^a + $^b }, 0 );
}
It's appealing just because it's so happy :).
The difference between this and:
class Array {
# ...
method sum($self:) {
.reduce( { $^a + $^b }, 0 );
}
# ...
}
Would be that the latter has access to Array's private data, while the
former does not. The calling conventions would not be any different
between the two.
Luke
Re: Why Cmap needs work (was Re: L2R/R2L syntax)
Date: Wed, 22 Jan 2003 10:38:23 -0800
From: Michael Lazzaro [EMAIL PROTECTED]
On Tuesday, January 21, 2003, at 03:52 PM, Dave Whipp wrote:
But in a for loop:
for 1,2,3,4 { ... }
for 1,2,3,4 - ($a,$b) {...}
its cuteness works because the brain sees it as a piping operator (even
though its not).
*** SPECULATION AHEAD ***
Note that Cfor allows you to name the arguments, using the pointy sub
rule:
for @a - ($a,$b) {...}
but note ALSO that it'd be great if Cmap and friends had that
capability, so you could Cmap two-at-a-time, etc. (Cgrep and
Csort don't really need it, but I *suppose* you could use it for
grepping/sorting tuples.)
I'm not sure whether you know that this already is the plan. The
following three are equivalent:
my @a = map { uc } @b;
my @a = map { uc $^a } @b;
my @a = map - $x { uc $x } @b;
And I believe two-at-a-time would also work.
So we want the pointy-sub rule for Cmap and friends too:
my @a = map - ($a,$b) {...}; # pass to {...} 2-at-a-time, as $a
and $b
Pretty neat.
But ignoring pointy-sub for the moment, and assuming that we in fact
used - and - to mean pre/post-invocant (e.g. pipes): if we defined
Cfor as just another word for Cmap, what we really want is rules
such that *all* of the following work. Question is, is it possible to
come up with something consistent. Maybe.
# void context
@a.map {...}
@a.for {...} # identical
@a - map {...} # identical
@a - for {...} # identical
@a - {...} # identical (a cool shorthand when given
a closure?)
for @a {...} # Doh! This wouldn't work
for @a : {...}# Hey, but this would (indirect object
syntax)
map @a : {...}# identical
for @a,@b,@c : {...} # is this OK?
for (@a,@b,@c) : {...}# OK, and better looking
# list context
my @a = @b - for {...}
my @a = @b - map {...} # identical
my @a = map {...} - @b # identical
my @a = for {...} - @b # identical
my @a - map {...} - @b# identical
my @a - for {...} - @b# identical
That works. Pretty darn well, too. (Note the critical bit, the
introduction of indirect object syntax to Cfor.)
Yeah, good point. Why is it that Cfor and Cmap, so similar in
nature, accept such different forms for their arguments?
But, I'll have to admit,
for @a,@b :- $a, $b { ... }
Doesn't look quite as nice as the older version :-
I'm thinking it would be a very good idea to unify Cfor and Cmap
in their argument style. I still think the distinction between
Cfor's void and Cmap's list context is a good one; i.e. don't make
them Ientire synonyms.
But it seems natural to have Cfor a method of CArray, however
unnatural that seems. I don't know, my thoughts are quite unclear at
this point; perhaps I'll write back when I've thought about this a bit
more.
Luke
Re: Why Cmap needs work (was Re: L2R/R2L syntax)
Michael Lazzaro writes: 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. Both are even clearer than the equiv: $out = $in.lex.parse.codify.optimize; Whether you would code a pipeline as L2R or R2L depends on the specific algorithm you're representing, and is purely a matter of taste... you'd probably use R2L in the same places as you use Cmap-like chaining in Perl5. I can't begin to justify why one should be superior to the other, and would certainly use them both. This explanation of (and rationale for) a post-invocant underpinning for l2r/r2l pipe-lining was wonderfully clear. I've also found that newish perl programmers frequently find Cmap and friends to be confusing, particularly when they are traveling in a pack (not to speak of an Cunpack). One question: How does this approach to building a pipe-lining syntax square with the alternative spelling of the assignment operator feature that's been discussed elsewhere in this thread? It's not immediately obvious to me how the post-/pre-invocant operation becomes an assignment at the end of the chain. In other words, are the first two code fragments above really equivalent to the third? Kwin
Re: Why Cmap needs work (was Re: L2R/R2L syntax)
--- Luke Palmer [EMAIL PROTECTED] wrote:
[[... Massive elision ...]]
I'm thinking it would be a very good idea to unify Cfor and Cmap
in their argument style. I still think the distinction between
Cfor's void and Cmap's list context is a good one; i.e. don't
make them Ientire synonyms.
But it seems natural to have Cfor a method of CArray, however
unnatural that seems. I don't know, my thoughts are quite unclear at
this point; perhaps I'll write back when I've thought about this a
bit more.
On a somewhat disjunctive note, if you're going to play games with
unifying Cfor and Cmap, let's undef the operation-order of map.
That is,
for (1,2,3) { print }
# 1 2 3
map { print } (1, 2, 3) # or however you rewrite the syntax
# ? ? ?
@a = map { print } (1, 2, 3)
for @a { print }
# 1 2 3
Note that the order of the results of map would still be guaranteed,
but not the order of operation. This is for threading, obviously, and
we should probably do the same thing everywhere we can, so that if you
want serial operation, you use for or some construction that honors
ordering attributes internal to the data.
The point is to warn people that preserving state in map blocks won't
work, although stateless data or statistics will:
map { count++; ... } @array # works fine -- count == array.length
map { %hist{$_}++ } @array # works fine -- hist{} counts occurrences
map { ...$last ...; # I do not think that code
last=$_; ... } @array # means what you think it means...
=Austin
Re: Why Cmap needs work
David Storrs [EMAIL PROTECTED] writes:
On Tue, Jan 21, 2003 at 03:52:30PM -0800, Dave Whipp wrote:
$a = sub ($a, $b) { ... }
$x = - ($y, $z) { ... }
The pointy-arrow doesn't buy anything here.
IMHO, it's actually a loss. I have yet to come up with any mnemonic
for pointy arrow means sub that will actually stick in my brain.
Every time I see this construct, I have to stop in my tracks and
mentally flip through the reference manual.
Personally, I think it looks a bit like a lambda on its side (and if
we're going to have unicode operators then I'd not be unhappy to see
'real lambda' being an equivalent to '-'.
--
Piers
Re: Why Cmap needs work (was Re: L2R/R2L syntax)
Michael Lazzaro wrote:
*Now*, what to do about the fantastic magic that pointy-sub provides?
The _spectacular_ win would be if we could just recognize an optional
parameter list as part of a block.
map @a : ($a,$b) {...} # params + closure = closure with params?
for @a : ($a,$b) {...}
So that anywhere you had a closure, you could put a paramlist in front
of it. Not likely we could get that to work, since best-case scenario
it would probably barf on $a and $b being undefined before it ever got
to the closure. But it might be possible, at the expense of some
parser complexity.
I agree that it might be difficult to recognize the ($a,$b) as a parameter list rather
than a list expression. Smalltalk marks block parameters this way:
b := [:a :b | a b]. Assign a two-paremeter block to b
^b value: 1 value: 2. Return the value of invoking b on 1 and 2
The [ makes it clear that a block is next; the : marks parameters and the | ends
the list. A literal translation to Perlish syntax would be
map @a { :$a :$b | $a + $b }
but then we get into discussions about Larry's 2nd law of colons. Besides, we perl
mongers already use | for a sufficient multitude of other things.
But my point is: just because C-ish programmers think (...){ ... } feels
parameterish doesn't mean that the parameter declaration has to come *before* the
opening curly brace. And no, despite two Smalltalk-related posts in the last three
days, I don't want to turn Perl into Smalltalk; I just think that Smalltalk has a nice
syntactic solution to the problem we're talking about here.
The problem is, I can't think of any syntaxes better than
map @a { $a $b: $a + $b } # hey, buddy, can you lend me a colon?
map @a { args $a, $b; $a + $b }
map @a { - ($a, $b); $a + $b }
map @a { $a, $b -$a + $b } # can't coexist with A4-style pointy subs
map @a { my^ $a, $b; $a + $b } # the ^ is reminiscent of map @a { $^a + $^b }
map @a {{$a, $b} $a + $b } # all other uses of consecutive curlies require
space: { {
map @a { EXPLICIT_ARGUMENTS_TO_FOLLOW $a $b ARGUMENTS_STOP_HERE $a + $b }
and they all look uglier than... well, um, uh... I want.
I have a strong suspicion that this possibility was carefully considered by {LW, DC,
...} (that's set notation, not a code block :) before the Apocalypse 4 pointy sub
syntax (and the for-loop syntax using it) was promulgated. And that it was rejected
because it's hard to come up with something that looks right. Even the Smalltalk
syntax is a tad awkward-looking to me, and the warpage that is necessary to make it
Perlish just compounds the problem.
Hmmm. I guess I didn't really say anything here, did I? Do I post these ruminations,
or should I just hit that cancel button before I open my mouth and remove all doubt?
Nah. I'm goin' for it: maybe somebody else will think of a syntax that looks right!
=thom
Must be a yearning deep in human heart to stop other people from doing as they
please. Rules, laws--always for the other fellow. A murky part of us, something we had
before we came down out of the trees, and failed to shuck when we stood up. Because
not one of those people said: 'Please pass this so I won't be able to do something I
know I should stop.' Nyet, tovarishchee, was always something they hated to see their
neighbors doing. Stop them 'for their own good'--not because the speaker claimed to be
harmed by it.
Manuel Davis O'Kelley
The Moon is a Harsh Mistress
This week's Perl 6 summary
The Perl 6 Summary for the week ending 20030119 Summary time again, damn but those tuits are hard to round up. Guess, what? perl6-internals comes first. 141 messages this week versus the language list's 143. Objects (again) Objects were still very much on everyone's mind as the discussions of Dan's initial thoughts about objects in Parrot continued. Jonathan Sillito put up a list of questions about Dan's original message which Dan answered promptly. Down the thread a little Dan mentioned that he hoped Parrot's objects would serve, reasonably unmodified for a bunch of languages (ie, he hoped that there wouldn't be a requirement for PythonRef/Attr/Class/Object etc), Chris Armstrong thought that, given what Dan had outlined so far, that wouldn't be straightforward. Dan thanked him for throwing a spanner in the works, asking for more details which Chris provided. Meanwhile Jonathan had some supplementary questions... Hmm... doing this blow by blow will take forever. Suffice to say that details are being thrashed out. At one point Dan's head started to spin as terminology mismatches started to bite, leading Nicholas Clark to suggest an entirely new set of terms involving houses and hotels (but with some serious underpinnings). http://makeashorterlink.com/?Y21952033 -- thread root, from last week. http://makeashorterlink.com/?M52912033 -- Jonathan's questions http://makeashorterlink.com/?A23912033 -- Chris throws a spanner http://makeashorterlink.com/?Z44922033 -- Nicholas tries for a monopoly on silliness Optimizing and per file flags Nicholas Clark wrote about requiring the ability to adjust compiler optimization flags on a per file basis (brought up by Dan on IRC apparently) and proposed a scheme. Quote of the thread (and quite possibly the year so far): When unpack is going into an infinite loop on a Cray 6000 miles away that you don't have any access to, there isn't much more you can do. Thanks for that one Nick. http://makeashorterlink.com/?I15965033 The draft todo/worklist Dan posted his current todo/worklist, which he described as reasonably high level, and a bit terse. I particularly liked the last entry Working Perl 5 parser. Surprisingly, there was very little discussion, maybe everyone liked it. http://makeashorterlink.com/?L56921033 Parrot Examples Joe Yates asked if we could add a helloworld.pasm to parrot/examples/assembly. Joseph Guhlin wondered what was so special about print Hello, world\n end that it would need a file of its own (though he did forget the end in his post, and segfaults are not really what you want in sample code). http://makeashorterlink.com/?E27912033 Thoughts on infant mortality (continued) Jason Gloudon posted a wonderfully clear exposition of the problems facing anyone trying to implement a portable, incremental garbage collector for Parrot which sparked a small amount of discussion and muttering from Dan about the temptation to program down to the metal. http://makeashorterlink.com/?X38931033 Operators neg and abs in core.ops Bernhard Schmalhofer posted an enormous patch adding neg and abs operators to core.ops. There were a few issues with the patch so it hasn't gone in yet and an issue with what underlying C functions are available reared its head too. http://makeashorterlink.com/?L29951033 The eval patch Leo Tötsch seems to have spent most of the week working on getting eval working and he opened a ticket on rt.perl.org to track what's happening with it. The response to this can be summarized as 'Wow! Fabulous!'. Once more, for Googlism, Leopold Toetsch is my hero. http://makeashorterlink.com/?I5A922033 Pretty Pictures Mitchell N Charity posted some pretty pictures that he'd generated with doxygen and graphviz. Most of the responses to this suggested he use different tools. Ah well. http://makeashorterlink.com/?B2B921033 Solaris tinderbox failures Andy Dougherty created an RT ticket for the Solaris tinderbox, which have been failing with the delightfully useful 'PANIC: Unknown signature type and wondered if things could be fixed up to be a little more informative. Apparently it was as issue with Leo's recently checked in eval patch. So Leo fixed it. http://makeashorterlink.com/?D1C925033 Parrot compilers Cory Spencer wondered about how the current compilers that target parrot work, noting that they seem to be duplicating a good deal of labour, and wondered if anyone had worked on a gcc like framework with a standardized Abstract Syntax Tree (AST). Everyone pointed him at IMCC. Gopal V also pointed out that, given the variety of implementation languages (C, Perl, Parrot...)
