RE: General Feelings on Apoc 3

[David Wheeler]

On Tue, 2001-10-09 at 22:42, Damian Conway wrote:
> Brent asked:
> 
>> If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a
>> low-precedence version of this?
> 
> I actually suggested exactly that to Larry a few weeks back.
> 
> He likes the idea, but is having trouble finding an acceptable name for the 
> operator.

I think the time has come, at last, to suggest a new operator -- and
perhaps this would be a good place for it. We need the 'doh' operator.
And to borrow from another thread, we might even be able to say

  doh!

;-)

David

-- 
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
   Yahoo!: dew7e
   Jabber:
[EMAIL PROTECTED]

RE: dor (was RE: General Feelings on Apoc 3 )

[Richard Nuttall]

> Bart Lateur:
> # On Thu, 4 Oct 2001 03:22:55 -0400, Michael G Schwern wrote:
> #
> # >Binary //
> # >
> # >The analogy to || is probably a bit too clever.  My first reaction
> # >was it's some sort of weird division operator.  But it's 
> servicable.
> #
> # I think it's very cute. I think of it as a "skewed or", 
> which is, er,
> # both what it both is, and what it looks like.
> 
> If we have 'and', 'or' and 'xor', can we have 'dor' (defined 
> or) to be a low-precedence version of this?

Should this be pronounced "duh" ? :-)

R. 

Re: General Feelings on Apoc 3

[Bart Lateur]

On Wed, 10 Oct 2001 15:42:29 +1000 (EST), Damian Conway wrote:

>Brent asked:
>
>   > If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a
>   > low-precedence version of this?
>
>I actually suggested exactly that to Larry a few weeks back.
>
>He likes the idea, but is having trouble finding an acceptable name for the 
>operator.

I'm not convinced it's that useful... The precedence of "dor" would be
lower than that of assignment. And it's precisely in assignment where
the "//" operator will come in very handy.

If you don't need to assign the value of the expression, you can just as
wel use defined():

defined($x = foo()) or die "Got an undefined value!";

Plus there's the matter of the name...

Do we really need low and high precedence equivalents of every boolean
operator? Next, you'll want a low precedence "?:" (or "??::"). We have
one already: if/else, but except in do blocks, you can't really use them
for expressions.

-- 
Bart.

RE: General Feelings on Apoc 3

[Damian Conway]

Brent asked:

   > If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a
   > low-precedence version of this?

I actually suggested exactly that to Larry a few weeks back.

He likes the idea, but is having trouble finding an acceptable name for the 
operator.

Damian

Re: General Feelings on Apoc 3

[Aaron Sherman]

On Tue, Oct 09, 2001 at 11:49:15AM -0700, Tim Conrow wrote:
> Brent Dax wrote:
> > 
> > If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a
> > low-precedence version of this?
> 
> Oh man. If we've gone so far as 'dor', why not make it 'doh' :-)
> 
> print stomach_state @beer,@donuts doh "burp!!!"

Well, that opens up a few possibilities...

First of all, we'll want to have a unary defaulting operator. For
example,

 $donuts

should check the type of $donuts and do the same thing as

$donuts is default

The universal definition of default should return undef so that

 $donuts doh "burp!!!"

Would do what you expect.

In our next issue, I'll be getting into the intricacies of the 
chainable diddly-aye-o suffix operator

-- 
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C  619E FC35 5713 2676 CEAF
  "Write your letters in the sand for the day I'll take your hand
   In the land that our grandchildren knew." -Queen/_'39_

Re: General Feelings on Apoc 3

[Tim Conrow]

Brent Dax wrote:
> 
> If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a
> low-precedence version of this?

Oh man. If we've gone so far as 'dor', why not make it 'doh' :-)

print stomach_state @beer,@donuts doh "burp!!!"


--

-- Tim Conrow [EMAIL PROTECTED]   |

Re: General Feelings on Apoc 3

[Aaron Sherman]

On Tue, Oct 09, 2001 at 08:35:10AM -0700, Brent Dax wrote:
> Bart Lateur:
> # On Thu, 4 Oct 2001 03:22:55 -0400, Michael G Schwern wrote:
> #
> # >Binary //
> # >
> # >The analogy to || is probably a bit too clever.  My first reaction
> # >was it's some sort of weird division operator.  But it's servicable.
> #
> # I think it's very cute. I think of it as a "skewed or", which is, er,
> # both what it both is, and what it looks like.
> 
> If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a
> low-precedence version of this?

I like "dor". "default" also seems natural, but long. Then again, I don't
think "else" is ever legal unless if appears between braces,
so that's another possibility if we wish to recycle syntax.

$live.happy else die "Sad"

Looks pretty nice. Perhaps confusing if folks think "else" and
"or" mean the same thing. If else seems to "iffish", perhaps it could
even be "or else", which is also not currently legal, AFAIK

$live.happy or else die "Sad"

Hmm gets me thinking evil thoughts... like having "else" be the
low-prec. //, and then "or else" be synonymous with ``else die "$!"''
so you get:

$live.happy or else

Read my lips: NO NEW TOKENS! ;-)

-- 
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C  619E FC35 5713 2676 CEAF
  "Write your letters in the sand for the day I'll take your hand
   In the land that our grandchildren knew." -Queen/_'39_

RE: General Feelings on Apoc 3

[Brent Dax]

Bart Lateur:
# On Thu, 4 Oct 2001 03:22:55 -0400, Michael G Schwern wrote:
#
# >Binary //
# >
# >The analogy to || is probably a bit too clever.  My first reaction
# >was it's some sort of weird division operator.  But it's servicable.
#
# I think it's very cute. I think of it as a "skewed or", which is, er,
# both what it both is, and what it looks like.

If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a
low-precedence version of this?

--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6

They *will* pay for what they've done.

Re: General Feelings on Apoc 3

[Bart Lateur]

On Thu, 4 Oct 2001 03:22:55 -0400, Michael G Schwern wrote:

>Binary //
>
>The analogy to || is probably a bit too clever.  My first reaction
>was it's some sort of weird division operator.  But it's servicable.

I think it's very cute. I think of it as a "skewed or", which is, er,
both what it both is, and what it looks like.

-- 
Bart.

Re: General Feelings on Apoc 3

[Rafael Garcia-Suarez]

David M. Lloyd wrote:
> On Thu, 4 Oct 2001, Michael G Schwern wrote:
> 
> > > Backtracking is at the heart of Logic Programming (or Declarative
> > > Programming, if you like). This is one of the 3 main programming paradigms
> > > (along with procedural and functional). The most popular Declarative
> > > language is Prolog. It is great for writing programs that are largely about
> > > resource allocation and constraints. There's some links to start you off
> > > here:
> > >
> > > http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?backtracking
> >
> > Sounds like a chess computer.
> 
> It kind of struck me that this type of concept might be handy for writing
> parsers directly in Perl without an 'intermediate' parsing language.  Or
> for making it easier to write such an intermediate language.

Backtracking is typically not used in parser implementations because
it's slow over other predictive techniques. It's needed in a few cases
of highly ambiguous languages (e.g. LL-infinite parsers).

Another idea : it should be possible to write makefile-like rules with
backtracking.

Re: General Feelings on Apoc 3

[Ted Ashton]

Thus it was written in the epistle of David Nicol,
> Michael G Schwern wrote:
> 
> > Binary ;
> > 
> > This worries me.  Giving ; two meanings makes basic language parsing
> > harder, which would be fine if there was a big payoff, but there's
> > not.  Just making shorthand for [[1,2,3],[4,5,6]] doesn't seem worth
> > it.  What am I missing here?
> 
> What you might be missing here (or what I might be improperly getting here)
> is that a good way to implement this sort of thing is with an exception
> handling parser.  The end-of-statement-while-brackets-are-open error
> can be trapped and turned into More Useful Syntax.

What worries me is that the end-of-statement-while-brackets-are-open error
would be trapped and turned into a More Serious Problem.  If, perchance, I'm
not the only one to have Accidentally Omitted a Closing Bracket, there may be
someone out there who prefers having the compiler object to the missing bracket
rather than have it attempt to run the code, assuming that the ; is really
*not* the end of the statement.  'Course, it has long been held that *any*
random sequence of characters is a valid Perl program, and this makes that a 
little more true.

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]) | From the Tom Swifty collection:
Southern Adventist University| "It doesn't seem one should sing nonsense
Deep thought to be found at  | syllables instead of words," said Ward
http://www.southern.edu/~ashted  | Swingle dubiously.

Another link [ Re: General Feelings on Apoc 3 ]

[raptor]

http://www.perlmonks.org/index.pl?node_id=71319&lastnode_id=71484

Re: General Feelings on Apoc 3

[raptor]

I think this would be interesting for U :")
http://www.cs.yorku.ca/Courses/3401/lectures/340198-11-27HTML/
http://www.cogs.susx.ac.uk/local/books/nlp-in-prolog/ch04/chapter-04-sh-1.5.
html#sh-1.5


| On Thu, 4 Oct 2001, Michael G Schwern wrote:
|
| > > Backtracking is at the heart of Logic Programming (or Declarative
| > > Programming, if you like). This is one of the 3 main programming
paradigms
| > > (along with procedural and functional). The most popular Declarative
| > > language is Prolog. It is great for writing programs that are largely
about
| > > resource allocation and constraints. There's some links to start you
off
| > > here:
| > >
| > > http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?backtracking
| >
| > Sounds like a chess computer.
|
| It kind of struck me that this type of concept might be handy for writing
| parsers directly in Perl without an 'intermediate' parsing language.  Or
| for making it easier to write such an intermediate language.
|
| - D
|
| <[EMAIL PROTECTED]>
|

Re: General Feelings on Apoc 3

[Michael G Schwern]

On Thu, Oct 04, 2001 at 08:29:10PM -0500, David Nicol wrote:
> > Binary //
> > 
> > The analogy to || is probably a bit too clever.  My first reaction
> > was it's some sort of weird division operator.  But it's servicable.
> 
> It echoes the switch from | to / within the IETF RFC syntax declaration
> language.  Apparently the global keyboard steering committee has
> deprecated the vertical bar.

You don't know how many times I've heard people complain that Perl
isn't catering enough to the needs of IETF RFC authors.  :-P

I have a feeling that echoing the IETF is just a coincidence.


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
 Hey, Schwern!  THERE IS A HUGE GAZORGANSPLATTEDFARTMONGERING-
LIGHTENINGBEASTASAURSOPOD BEHIND YOU!  RUN, BEFORE IT GAFLUMMOXES YOUR
INNARDLYBITS!

Re: General Feelings on Apoc 3

[David Nicol]

Michael G Schwern wrote:


> Binary ;
> 
> This worries me.  Giving ; two meanings makes basic language parsing
> harder, which would be fine if there was a big payoff, but there's
> not.  Just making shorthand for [[1,2,3],[4,5,6]] doesn't seem worth
> it.  What am I missing here?


What you might be missing here (or what I might be improperly getting here)
is that a good way to implement this sort of thing is with an exception
handling parser.  The end-of-statement-while-brackets-are-open error
can be trapped and turned into More Useful Syntax.


Alternately, semicolon only means statement-end when all brackets are
balanced.


Suddenly we have 
more syntax to play with: an easy-to-find separator is no longer pinned
into its one role as statement terminator, to use a chess metaphor.

The list-of-lists is an example of what can be done; it is not the point
of the innovation.  Things like syntaces for declaring your named
arguments come to mind as a more intense use of this feature. I am not
caught up with the state of the art enough to produce a compliant example
at this time.


> Binary //
> 
> The analogy to || is probably a bit too clever.  My first reaction
> was it's some sort of weird division operator.  But it's servicable.

It echoes the switch from | to / within the IETF RFC syntax declaration
language.  Apparently the global keyboard steering committee has
deprecated the vertical bar.

 
> Hyperoperators:
> 
> I sort of understand it, but don't really grok it.  I can sort of
> thing of ways it might eliminate the need for a few maps and
> foreaches.  Damian, might I request some clarification in Exogenesis?

I am not Damian, but I'll try:

The feature is not, IMO, big enough to warrant giving it the
really-big-sounding name "hyperoperator" but it is as good as any
and no other (?) language has it at this particular level of explicitness
(overloads on C++ container classes notwithstanding.)

There is no way to disambiguate the do-once case from the do-for-each
case without some syntax of some kind, so hat-operator is pressed into
the role.

I suppose descent into LoL and attitude towards multidim is up to
the operator getting hyperized -- that is a point for regularization
of some kind, cultural if not linguistic.


 
> Backtracking:
> 
> Ok, I don't get it at all.  Damian, clarification?

Me neither.  I had thought that backtracking dealt with
remembering one's side effects so they could be unwound.
The RFC in question was completely incomprehensible to me
as well, and possibly written by someone who was not aware
that Perl's logical operators short-circuit by definition.

What am I missing?

Re: General Feelings on Apoc 3

[Damian Conway]

   > Or even
   > 
   > for my $x (1..98) {
   >   for my $y (1..(99-$x)) {
   > for my $z (1..(100-$x-$y)) {
   >   print "$x, $y, $z\n" if $x ** 2 = $y ** 2 + $z ** 2;
   > }
   >   }
   > }

Sure. Depending on whether you want combinations or permutations.

Damian

Re: General Feelings on Apoc 3

[Randal L. Schwartz]

> "Damian" == Damian Conway <[EMAIL PROTECTED]> writes:

Damian> Personally, I think:

Damian> foreach my $x (1..99) {
Damian> foreach my $y (1..99) {
Damian> foreach my $z (1..99) {
Damian> print "$x, $y, $z\n" if $x**2 == $y**2 + $z**2;
Damian> }}}

Damian> is much cleaner.

Or even

for my $x (1..98) {
  for my $y (1..(99-$x)) {
for my $z (1..(100-$x-$y)) {
  print "$x, $y, $z\n" if $x ** 2 = $y ** 2 + $z ** 2;
}
  }
}

Damian> But it certainly does demonstrate TMTOWTDI. ;-)

TMT2WTDI :-)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: General Feelings on Apoc 3

[Damian Conway]

   > >> Backtracking:
   > >> 
   > >> Ok, I don't get it at all.  Damian, clarification?
   > > 
   > > Nothing to clarify. Larry punted (to a later Apocalypse).
   > > 
   > > Okay. That's a cop-out. He's basically saying that you can write
   > > C and C yourself as:
   > 
   > 
   > I understand that much.  What I don't quite get is the utility.
   > There's some hand-waving in the RFC about making parsers easier.

Parsing will not be the major application, I think. 

To see the utility, you need to look at a language whether this feature
is already central to the language. Icon 
is a good example.

To see how backtracking might work in Perl, here's an program (adapted
to RFC 104 syntax) that prints out Pythagorean triangle triplets with
side-lengths less than 100:

  $x=100;
{ $y=100; --$x  }
andthen { $z=100; --$y  }
andthen {   { --$z } andthen { $x**2 == $y**2 + $z**2 } }
andthen {   print "$x, $y, $z\n";  0};


Incidentally, that's why Larry was musing over the idea of the left operand's
scope extending to the right operand. If that were the case, we could make $x,
$y, and $z safely lexical:

  my $x=100;
{ my $y=100; --$x  }
andthen { my $z=100; --$y  }
andthen {  { --$z } andthen { $x**2 == $y**2 + $z**2 } }
andthen {  print "$x, $y, $z\n";  0};


and the later blocks would still see them.

Personally, I think:

foreach my $x (1..99) {
foreach my $y (1..99) {
foreach my $z (1..99) {
print "$x, $y, $z\n" if $x**2 == $y**2 + $z**2;
}}}

is much cleaner.

But it certainly does demonstrate TMTOWTDI. ;-)

Damian

Re: General Feelings on Apoc 3

[David M. Lloyd]

On Thu, 4 Oct 2001, Michael G Schwern wrote:

> > Backtracking is at the heart of Logic Programming (or Declarative
> > Programming, if you like). This is one of the 3 main programming paradigms
> > (along with procedural and functional). The most popular Declarative
> > language is Prolog. It is great for writing programs that are largely about
> > resource allocation and constraints. There's some links to start you off
> > here:
> >
> > http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?backtracking
>
> Sounds like a chess computer.

It kind of struck me that this type of concept might be handy for writing
parsers directly in Perl without an 'intermediate' parsing language.  Or
for making it easier to write such an intermediate language.

- D

<[EMAIL PROTECTED]>

Re: General Feelings on Apoc 3

[Michael G Schwern]

On Thu, Oct 04, 2001 at 06:35:51PM +1000, Jeremy Howard wrote:
> > I've been playing with Ruby, which has a similar feature.  @foo is an
> > object instance variable.  Inside a class definition, foo() is a
> > object method call on the current object.  Outside it's a class method
> > call on the current class.  Works out very nicely under the fingers.
> >
> I really hope that the unary . is required (as Larry suggested)--I don't
> want foo() to be a method  call on the current object unless the '.' prefix
> is there.

It has to be that way in Perl, I'd think, since we have real functions
(as opposed to method calls that look like functions) and you have to
distinguish between the two somehow.



> My favorite introduction to the joys of
> array-oriented languages is here:
>   http://www.jsoftware.com/primer/main.htm

AUUUGHH!  MONADS!  /me claws out his eyes.

Sorry, I think I read one too many "Monads Will Save The Universe,
Revive Functional Programming, Make You Younger And Smell Better and
Scrape the Burnt Part Off Your Toast" papers.


> To describe it as just eliminating 'the need for a few maps and foreaches'
> is like describing Perl's OO as just eliminating the need to create a little
> hash of references to packages. Although it is somewhat accurate in theory,
> it misses the point that the syntax enables a programming paradigm that is
> more rich and appropriate for certain problem domains

Having made that same argument myself for other things, I'll try to
keep an open mind about it.


> > Backtracking:
> >
> > Ok, I don't get it at all.  Damian, clarification?
> 
> Backtracking is at the heart of Logic Programming (or Declarative
> Programming, if you like). This is one of the 3 main programming paradigms
> (along with procedural and functional). The most popular Declarative
> language is Prolog. It is great for writing programs that are largely about
> resource allocation and constraints. There's some links to start you off
> here:
> 
> http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?backtracking

Sounds like a chess computer.


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
GOD made us funky!

Re: General Feelings on Apoc 3

[Michael G Schwern]

On Thu, Oct 04, 2001 at 05:59:53PM +1000, Damian Conway wrote:
>> Hyperoperators:
>> 
>> I sort of understand it, but don't really grok it.  I can sort of
>> thing of ways it might eliminate the need for a few maps and
>> foreaches.  Damian, might I request some clarification in Exogenesis?
> 
> Well, I'll probably clarify them in Exegesis instead.
> "External birth" would seem a bit extreme here. ;-)

Sorry, didn't mean to imply that you'd laid an egg. ;)


>> Backtracking:
>> 
>> Ok, I don't get it at all.  Damian, clarification?
> 
> Nothing to clarify. Larry punted (to a later Apocalypse).
> 
> Okay. That's a cop-out. He's basically saying that you can write
> C and C yourself as:


I understand that much.  What I don't quite get is the utility.
There's some hand-waving in the RFC about making parsers easier.


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
Obscenity is the last resort of the illiterate, Mother Fucker
-- KAL

Re: General Feelings on Apoc 3

[Jeremy Howard]

Michael G Schwern wrote:
> Binary and unary dot:
>
> This makes me *very* happy.  This is probably the best thing I've
> heard all day.
>
Seconded.

> I've been playing with Ruby, which has a similar feature.  @foo is an
> object instance variable.  Inside a class definition, foo() is a
> object method call on the current object.  Outside it's a class method
> call on the current class.  Works out very nicely under the fingers.
>
I really hope that the unary . is required (as Larry suggested)--I don't
want foo() to be a method  call on the current object unless the '.' prefix
is there. Also, I hope we see a with{} block that lets you specify the
object to use as the implicit LHS of the unary dot.

> Binary ;
>
> This worries me.  Giving ; two meanings makes basic language parsing
> harder, which would be fine if there was a big payoff, but there's
> not.  Just making shorthand for [[1,2,3],[4,5,6]] doesn't seem worth
> it.  What am I missing here?

I'm not sure if you're missing anything or not. Have a look at RFC 205 which
proposes an in-list role for ';', which is absolutely crucial to the whole
package of array RFCs (202-207). I suspect Larry has something up his sleave
here though (since his proposals often seem to make more sense in
hindsight--kinda like Nostradamus, only not in quaterns), so perhaps we have
to faith in the ineffable plan for the time being.

> Lazy lists:
>
> Neat!  It'll be hell to make them work right, but neat!

Damian retracted RFC 024, which specified infinite lists, and I re-opened
that when I started the lazy-list RFC 082 that Larry discusses. After
numerous people insisted that infinite lists were impossible (a fact that
I'm yet to be convinced of given that they exist in other languages) I
removed the infinite list stuff from RFC 082 and just left in the nifty list
comprehension syntax. Damian's advice to me at the time was that there's
enough meat in RFC 082 without the infinite list stuff, so we'd be best off
keeping the issues separate; in hindsight it was good advice. Without the
infinite list requirement RFC 082 isn't "hell", although avoiding
unnecessary calculation of intermediate elements will be a challenge (and
failure to do this well just makes things slow, not broken). Anyway, Larry
seems to have bought back elements of RFC 024 back into his discussion of
RFC 082--but I think we should continue to keep the two proposals reasonably
distinct as we consider their design and implementation.

> Hyperoperators:
>
> I sort of understand it, but don't really grok it.  I can sort of
> thing of ways it might eliminate the need for a few maps and
> foreaches.  Damian, might I request some clarification in Exogenesis?
>
Err... I'm not Damian, but can I answer anyway? ;-)

In general, array operations in languages that support them (most notably
APL and J; also Haskell, Mathematica, and many more) almost entirely remove
the need for loops. Mathematical notation is a good example of a language
with rich array operations, allowing the manipulation of multi-dimensional
arrays (except that mathematicians call them 'tensors' to sound impressive
:-) using a clear and brief syntax. My favorite introduction to the joys of
array-oriented languages is here:
  http://www.jsoftware.com/primer/main.htm

To describe it as just eliminating 'the need for a few maps and foreaches'
is like describing Perl's OO as just eliminating the need to create a little
hash of references to packages. Although it is somewhat accurate in theory,
it misses the point that the syntax enables a programming paradigm that is
more rich and appropriate for certain problem domains (explicit loops and
functional programming are not really good partners). In addition to
hyperoperators, Damian will tomorrow discuss adverbs in general. Again, the
J Primer linked above is a wonderful introduction to adverbs and
conjunctions.
>
> Backtracking:
>
> Ok, I don't get it at all.  Damian, clarification?

Backtracking is at the heart of Logic Programming (or Declarative
Programming, if you like). This is one of the 3 main programming paradigms
(along with procedural and functional). The most popular Declarative
language is Prolog. It is great for writing programs that are largely about
resource allocation and constraints. There's some links to start you off
here:

http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?backtracking

http://www.cse.unsw.edu.au/~billw/prologdict.html#backtrack

http://www.cee.hw.ac.uk/~alison/ai3notes/chapter2_3.html#SECTION0030
000

Re: General Feelings on Apoc 3

[Damian Conway]

 
   > Hyperoperators:
   > 
   > I sort of understand it, but don't really grok it.  I can sort of
   > thing of ways it might eliminate the need for a few maps and
   > foreaches.  Damian, might I request some clarification in Exogenesis?

Well, I'll probably clarify them in Exegesis instead.
"External birth" would seem a bit extreme here. ;-)

   
   > Polymorphic comparisons:
   > 
   > I'm firmly with Larry here.  I have oogy feelings about $foo == $bar
   > doing different things depending on the value of $foo and $bar.  I'm
   > also a more than a little afraid at what 42 == "forty-two" should do.

It's no longer a problem. Multiway comparisons and NaN-ification on
numerified non-numeric strings fix it. See Exegisis 3 tomorrow.

   
   > Backtracking:
   > 
   > Ok, I don't get it at all.  Damian, clarification?

Nothing to clarify. Larry punted (to a later Apocalypse).

Okay. That's a cop-out. He's basically saying that you can write
C and C yourself as:

my sub operator:andthen is prec(\&operator:and) (&block1, &block2) {
while (block1()) {
return 1 if block2();
}
return 0;
}

my sub operator:orthen is prec(\&operator:or) (&block1, &block2) {
while (1) {
return 1 if block1();
return 1 if block2();
}
}

but that it would be better if C's lexical scope were preserved
until the outcome of C is known.

Larry has a marvellous proof of this (involving continuations), but as there
wasn't enough room in the margin of this Apocalypse to explain it, he'll
be doing so in a later design document.

;-)

Damian

General Feelings on Apoc 3

[Michael G Schwern]

I'm going to post my general feelings on Apoc 3.  Rather than just
post up about things I don't like, I'll also mention what I do like
and what I just don't understand.  If I don't mention a piece, it
usually means I didn't really have much feeling one way or the other.

First, a general observation.  Perl 6 is looking more like Ruby every
day.  (Language thievery)++

Second, I like the way everything-as-object is being unobtrusively
weaved into the language.


Binary and unary dot:

This makes me *very* happy.  This is probably the best thing I've
heard all day.

I've been playing with Ruby, which has a similar feature.  @foo is an
object instance variable.  Inside a class definition, foo() is a
object method call on the current object.  Outside it's a class method
call on the current class.  Works out very nicely under the fingers.

For anyone that writes a lot of OO code, the pleasure of not having to
write $self-> (or $self.) six thousand times a day is well worth the
trip.


Unary * and list context:

This is a change for the better.  The specifics of the * syntax is a
little odd, but being able to pass two arrays into a function without
fumbling with prototypes will be welcome.


Concatenation:

I couldn't care less what string concat is.  God, let's argue about
something more interesting.


Binary ;

This worries me.  Giving ; two meanings makes basic language parsing
harder, which would be fine if there was a big payoff, but there's
not.  Just making shorthand for [[1,2,3],[4,5,6]] doesn't seem worth
it.  What am I missing here?


Trinary ??::

I'm rather surprised that I have no problems with this.


Binary //

The analogy to || is probably a bit too clever.  My first reaction
was it's some sort of weird division operator.  But it's servicable.


Filetests:

The most interesting thing I see here is the embracing of the
everything-as-object feature and seeing its first real payoff to make
neat DWIMery possible.


tr///:

I never thought I'd hear Larry use the term "sucky"


Lazy lists:

Neat!  It'll be hell to make them work right, but neat!


Hyperoperators:

I sort of understand it, but don't really grok it.  I can sort of
thing of ways it might eliminate the need for a few maps and
foreaches.  Damian, might I request some clarification in Exogenesis?


Polymorphic comparisons:

I'm firmly with Larry here.  I have oogy feelings about $foo == $bar
doing different things depending on the value of $foo and $bar.  I'm
also a more than a little afraid at what 42 == "forty-two" should do.


Backtracking:

Ok, I don't get it at all.  Damian, clarification?


=~ and 'apply-to':

"But by and large, I think I'd rather see:  @foo.grep {!m/\s/}"

Yay, CLU iterators!


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
That which stirs me, stirs everything.
-- Squonk Opera, "Spoon"