Re: == vs. eq
Luke Palmer <[EMAIL PROTECTED]> writes: > However, my problem remains. What does the poor generic programmer do > when he needs generic equality!? unfortunetly, no such thing exists. see: http://xrl.us/fdz and http://www.nhplace.com/kent/PS/EQUAL.html although the specifics are common lisp related the underlying ideas are equally valid to perl. -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
Re: A6 questions
Chris Dutton <[EMAIL PROTECTED]> writes:
> On Sunday, March 16, 2003, at 05:09 PM, David Storrs wrote:
>
> > ==QUESTION
> > - Page 8 says "In some languages, all methods are multimethods." I
> > believe that Java is one of these. Is that right and what are some
> > others? (This is really just curiousity.)
> > ==/
>
> Doesn't C++ work this way? Also I believe Pike allows overloading of
> methods by default.
While this isn't really perl6 related it gives me a good opportunity
to say why i WANT multimethod dispatch (and not just method
overloading (or overridding or whatever it's called)):
Let's say we have three classes:
Message
BroadcastMessage
MulticastMessage
Message is an abstract base class (or an interface) and
BroadcastMessage and MulticastMessage are conrete (instantiable)
classes which inherit only from Message.
Assuming we have a third class named MessageHandler with two methods:
method send(BroadcastMessage) { ... }
method send(MulticastMessage) { ... }
(one method specialized for arguments of the BroadcastMessage class
and one for arguments of the MulticastMessage class.)
The problem arises when we have some code which wants to use
MessageHandler's send method without caring about the type of Message:
example, suppose we have the method foo:
method foo(Message a_message, MessageHandler a_message_handler) {
...
a_message_handler.send(a_message);
...
}
Even though Message is an abstract class, and we've defined a send
method for both BroadcastMessage and MulticastMessage the call to send
with a Message argument is a compile time error becuase there is no
send method declared to tkae a Message object as an argument. This, i
hope, also shows the difference between multi-method and single-method
dispatch: _when_ the selection of which method to call happens, with
single-method we look at the args at compile time and the object at
run time, with multi-method we consider everything at run time.
While there are work-arounds (like making send a method of the Message
class) these just move the problem around until our particular app
doesn't mind, they do not _solve_ the problem.
It may just be me, but this has annoyed me more than once in my life
with Java.
> ==QUESTION
> - Also on page 9, concerning macros:
>
> "...while a macro's name may be installed in either a package
> or a lexical scope, its syntactic effect can only be lexical,
> from the point of declaration (or importation) to the end of
> the current lexical scope."
>
> Does that mean that I cannot define a bunch of commonly-used macros
> in a single file and then use them in different files?
> ==/
note the bit about "(or importation)". Just import the commonly-used
macros in every file you want, they'll be visibile from the line that
imports them until the end of the file (or the end of the current
block).
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Re: labeled if blocks
Larry Wall <[EMAIL PROTECTED]> writes:
> On 27 Oct 2002, Marco Baringer wrote:
> : why not use -> to create a sub which you can return from?
> :
> : if $foo -> {
> : ...
> : return if $bar;
> : ...
> : }
>
> Except that by the current rule you can only C from something
> that is declared with the word "sub". ->{...} is still just a fancy
> block from that perspective.
since what we're talking about is what most people consider a return i
think it would be a good idea to resue the word return (and therefore
the concept) as much as possible. may i suggest 'return [VALUE] from
BLOCK'?
where BLOCK can be all kinds of things
- C - innermost while/for/foreach
- C - current sub
- C - innermost topicalizer
- C - exit
- C - innermost block
- C - (undocumented) intercal's come from.
- BLOCK_NAME - name of lexically enclosing block.
- anything else - reference to a block. this is debatable, if you're
using return like this you should probably be using an exception.
VALUE would default to undef (just like C does under perl5, so
perl6's C is a synonym for C).
--- how do we give blocks names?
has any thought been given to how you name blocks? how about:
{ BLOCK_NAME: ... }
i'd like to get away from
BLOCK_NAME: op {
this blcok is actually named BLOCK_NAME
}
as i always thought that was the wrong place for the name, but there
may be a reason for that which escapes me.
of course, if blocks are objects and i can somehow get at the current
block this should be:
{
Block.name = "BLOCK_NAME";
...
if $cond {
return $foo from "BLOCK_NAME";
}
}
or (and this looks really weird):
{ ...
if $cond {
return $foo from "BLOCK_NAME";
}
...
}.name("BLOCK_NAME") # maybe a semicolon too, maybe not...
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Re: labeled if blocks
"Steve Canfield" <[EMAIL PROTECTED]> writes:
> Will Perl6 have labeled if blocks? Like this:
>
> BLAH:
> if ($foo) {
> ...
> last BLAH if $bar;
> ...
> }
why not use -> to create a sub which you can return from?
if $foo -> {
...
return if $bar;
...
}
this of course means you can't directly return from the sub (or whatever) in
which the if (or given or while or for) is nested...
slightly related:
what happens to the return value of the subs passed to for, if, while
and given statements? (what does '$foo = if $bar { ... } else { ... }'
do?)
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
Re: [OT] Power of Lisp macros?
Luke Palmer <[EMAIL PROTECTED]> writes: > If you define "powerful" as "can do more things," then of course not. > Lisp is implemented in C, and C's macros are certainly not essential [aside: most "major" common lisp implementations (cmucl, sbcl, openmcl, mcl, allegro and lispworks) are all native compilers implemented in lisp (and some assembler for boot straping). CLISP is the only "major" implementation whose core is in fact implemented in a C dialect (for speed reasons (the virtual machine is really slow))] >But think of what macros in general provide: > > * Multi-platform compatability > * Easier maintenance * Creating/Embedding custom languages. aka - adapting the langauge to your problem domain. common lisp macros allow you to locally extend the vocabulary of common lisp in the same way engineers have locally (ie within the engineering domain) extended english with new syntax/semantics to deal with engineering problems. macros are functions which are run when the source code is read (parsed). the argument to a macro is source code (expressed as a data structure and not simple text) and the return value is source code (not text). this is a fundamental difference between C's text-processing macros, without this macros lose most of their power and become too hard to write to be used. common lisp's LOOP is a great example of what you can do with macros (and the best iteration construct around). see http://www.lispworks.com/reference/HyperSpec/Body/06_a.htm for the spec and http://www.ai.sri.com/~pkarp/loop.html for a tutorial. random points and counter-points: - what macros are really good at is embedding mini-languages and creating new idioms, this often goes with, but is not nessecarily related to, reducing lines of code. example: CLOS/MOP (common lisp object system/meta object protocol) are implemented as macros on top of non-OO lisp (this statement maybe be a lie if you go deep enough into the specifics of some implementations). - the power of lisp's macros is that they allow you to perform arbitrary code transformations by working with code as if it was data. at one point there was discussion about having perl subs with "auto-args" (i forget where i read about this) where by the arguments to the sub where determined by parsing the body of the sub itself and looking at what variables where used, this is a trivial macro in lisp. adding this to perl5 required a source filter which took forever to write and was never used because is was never reliable enough (this may say more about my capabilities as a programmer than about perl5 source filters). - everything you can do with macros you can do without, since macros always get expaned (translated) into "regular" common lisp code. however, sometimes (like with CPS) hand writing the output is prohibitly difficult. - some people consider macros to actually reduce maintainability since they perform arbitrary code manipulations, so you have _no_ idea of what is going on if you don't know what the macro does. macros which introduce new symbols are especially vulnerable to this. - any sufficently powerful tool can be used to shot yourself in the foot (or blow off your head). i doubt this java-esque argument (let's "protect" the programmers from themselves) has any weight with perl programmers, but it's something i've heard more than once. - writing realiable/robust source filters is hard (do able, but hard, even with The Damien's Filter::Simple). writing grammars is better, but still hard, and more importantly, both require a rdically different mind set from "regular" programming. the ease of writing lisp macros is largely due to the fact that lisp has no syntax (almost), and that lisp's syntax is programmable. perl6 will have the second and can't do much about the first (sort of goes against "different things should look different"). just another lurker's rant... -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
