Re: macros
On May 22, 6:02 pm, Seamus MacRae <smacrae...@live.ca.nospam> wrote:
Alessio Stalla wrote:
On May 22, 11:23 am, Seamus MacRae <smacrae...@live.ca.nospam> wrote:
Sure they do. Either two identical names collide, or they reside in
distinct namespaces. You just insinuated that methods and classes do=
not
reside in distinct namespaces (quoted material, very top of this pos=
t).
Therefore if one of each with the same name resides in a single one,
they collide. It's elementary logic, Alessio.
Do a field named foo and a method named foo in the same class collide
in Java? No.
Because they reside in different namespaces. Java doesn't just conside=
r
them both "symbols" and throw them together into a single namespace;
instead, it creates separate ones within the class for fields and for
methods.
However, an earlier poster said that Common Lisp just considers method
names and the like to be "symbols" and throws them all together into a
single namespace per package.
That was me.
So now you're disagreeing with *yourself*? Well, I guess you might
sometimes change your mind about one of these things, but still, the
timing in this case was atrocious!
If that earlier poster was incorrect, take it up with him. Attacking m=
e
for simply quoting him is pointless, rude, and should make you feel
guilty now that you realize the attack was aimed at the wrong target a=
nd
you just smacked an innocent bystander for someone else's offense.
The earlier post WAS correct.
But it wasn't. Or else the later one wasn't correct. You can't have it
both ways! Either they all go into one name-resolution pool or they
don't; they can't both do so and not do so at the same time.
And, no clashes!!
So, the earlier post WAS incorrect.
The meaning of a symbol is apparent from the context. Yet there is a
single namespace, the package.
Not consistent. Either the former or the latter is false. I think you
have package and namespace confused, and the package actually has a
separate namespace in it for each of several kinds of thing. In other
words, it doesn't just have symbols, it has methods separate from
variables separate from classes etc.; it has some notion of which of
these is which and keeps them tidy.
No, I don't. Packages in Lisp are name-spaces: spaces of names, sets
of names. They contain - names. Just names, nothing else. Really.
Names can refer to many things. They can have many meanings attached.
But those meanings are not attached using packages.
The same is true in Java, somehow, too: if you use a Class as a
namespace (classes are indeed namespaces in Java, though not the only
kind of namespace).
class.getField("foo") returns a field, class.getMethod("foo") returns
a method, yet the name is always "foo". See? Lisp works like this.
When in Lisp you use the symbol foo where a variable is expected, the
compiler uses foo as a variable name; when you use foo where a
function name is expected, the compiler uses foo as a function name;
and so on. But foo is always the same symbol, the very same object.
Java on the other hand has "packages" which are namespaces, but also
are a sort of "logical directories" that contain resources (typically
classes). Lisp is not like that at all.
there are multiple namespaces here (one for
variables, one for classes, one for functions and macros, ...)
An admission of the truth at last?
I'm using "namespace" improperly here, in hope to make things clearer
to you. Probably it's more correct to say there are more symbol-to-
object mappings.
the method MY:frobnodicate(YOUR:quux) which is different from
the method YOUR:frobnodicate(MY:quux) which is different from
the method YOUR:frobnodicate(YOUR:quux)
The methods, yes. It's the little bit of code containing the dispa=
tch
table that concerns me.
Someone has to add a (YOUR:quux YOUR:quux) dispatch to MY:frobnobd=
icate, for example.
Only if he/she wants to use MY:frobnobdicate with YOUR:quux, which =
may
or may not make sense depending on what MY:frobnobdicate and YOUR:q=
uux
mean.
In your example, though, this combination was used, along with all t=
hree
other combinations of whose frobnobdicate and whose quux.
My example was meant to show all the possible combinations, not
suggest they usually are all used.
Well, I was simply considering the possibility that they ARE all used,
and it seems that using two of them causes problems.
I don't think it can cause any problem whatsoever.
By "problems" in this instance I meant scoping headaches for the
programmer, rather than actual failures of the code.
Ok, but this case is like if you had, in Java,
a.X.method(a.Y thing)
a.X.method(b.Y thing)
b.X.method(a.Y thing)
b.X.method(b.Y thing)
used in the same file; not very probable (and exactly as problematic
in Java as in Lisp).
[snip]
The "natural encapsulation" is only natural in Java, C++ and language=
s
with a similar kind of OO. It's not the only possibility. In Lisp, th=
e
natural encapsulation is at the package level
My point was that Lisp's encapsulation granularity is much fucking
coarser!! Are you fucking dense?
If I use the "private" symbol P::X, this means that anything named
P::X is private: the CLASS P::X, the VARIABLE P::X, the FUNCTION P::X.
Oh God, it just gets worse and worse! Now you say your system's bollixed
up enough that you can't even have, say, a private variable named foo
and a public method named foo in the same place? Who thought this up?
Why would you make private apply to everything of the same NAME,
regardless of whether that name was overloaded? Why?
It's the price you have to pay for having a general naming mechanism
like packages. It's not really a big price, since I've never come up
with a case where it actually gave problems. Naming conventions help,
of course (e.g. variables are usually named *variable-name* with
asterisks).
Oh, nevermind. It's wacky, you like it anyway, I don't, and that's the
end of the matter. There's really little point in continuing this.
If you think so.
How is this "much ****ing coarser" than Java?
It's spelled "fuck". With an F.
Sure, I can't have function X private and class X public.
Let's tick things off shall we? One. More. Time.
1. Your module size is like in C, a few per program (plus libraries'),
rather than like Java or even C++, one per class.
Imagine C++ only with "private" visible to everything in the same
.cc file, or all pairs of classes in a single source file implici=
tly
mutual "friends".
C does not have namespaces IIRC. If it had, then yes, CL would be
similar to C (but with the huge benefit that symbols are first-class
and you can manipulate them at runtime).
2. The encapsulation is extremely weak even so. Not only can you
circumvent it by adding a single colon to a scope operator somewh=
ere,
a) it's right next to another colon, so an easy typo to make simp=
ly
by bouncing a key;
No, since you have to type the symbol name, so you have to add a colon
AND mistype the symbol name so that accidentally you hit an existing
private symbol - quite unlikely.
b) you can presumably automate even the one lousy extra colon using a
macro;
No, you can't, since symbol resolution is done at read-time, before
macros are expanded.
and c) it will look enough like normal to
be easily overlooked and mistaken for innocent code, unlike, say,
Java reflection and setAccessible(true) calls. Heck you can even =
get
your Java IDE to find all setAccessible calls on reflection API
objects without false positives and throughout the code base, if =
your
IDE is decent enough. Meanwhile :: is a search that will have fal=
se
positives I guarantee it. All two-or-less-character searches do.
Yet it never gave me problems. Because it's not easy to make a mistake
(see above).
Besides that, what can you express in Java that you cannot in Common
Lisp?? (apart from the fact CL has no "protected")?
Technically nothing since they're both Turing complete. But much that is
decent and good in Java would require implementing a Java emulator in CL
to get in CL. (The JVM spec is readily available, so this should be
trivial right?)
Ok, turing-equivalence apart, I meant with current Java and CL, and
I've shown you, too.
Class-granular "private" comes to mind in particular.
You have it. Just make the slot name private.
CL IS NOT JAVA and IT WORKS DIFFERENTLY.
Exactly my point. It works differently, and in this case, differently =
worse. Now every unrelated pair of "close" methods collides, unless you
start being creative with your thesaurus, and then code gets less
readable and there's more and harder memorization to learn to use the
darn thing.
close(file), close(socket), close(string-output-stream) BELONG ALL TO
THE SAME GENERIC FUNCTION
The one for iostreams.
What about closing windows? Oops, no windows, forgot. :P Well, I'll
think of *something*...
Those about closing windows are different verbs, yes. There are not
many cases like this. How many more totally unrelated things can you
close?
Sorry for "shouting"
No you're not, not one damn bit.
I meant WRITING IN ALL CAPS.
I really don't know how to explain it to you, yet it seems simple to
me.
I'm sure the guys down at Bellevue that think they're Napoleon think the
same thing when they try to get people to believe them.
yeah, right...
Heh, Graphics2D is really an example of what I was saying :) it has
drawPolygon, drawOval, drawText, and a few other drawSomething. What
if I wanted it to draw the cool chart generated by my favourite
library?
The chart would be an instance of some class, say Chart, implementing
the other interface, the one with a drawOn(Graphics2D) method specifie=
d.
The drawOn() method would call the Graphics2D methods. Code that wante=
d
to draw a chart on a Graphics2D would call the chart's drawOn() method
with the appropriate parameter. Different chart instances would produc=
e
different drawings.
So while I can drawRect() and drawCircle(), I can't drawChart() but I
have to use a workaround, Chart.drawOn(graphics).
That's not a workaround. We can also have Circle.drawOn, Rect.drawOn,
etc. if we want to be able to do them all consistently. Or we can add a
generic draw() to Graphics2D that takes a Drawable and just calls
argument.drawOn(this). (Assuming we control Graphics2D.) Then you can
happily do graphics.draw(chart).
I need ALL objects that can be drawed implement the Drawable
interface. Unfortunately it's unlikely I'll ever have control on ALL
classes that can be drawed...
Why? You're the one designing the system, hypothetically.
So I end up having "primitive" drawXXX on Graphics,
com.mypackage.Drawable.drawOn(Graphics),
com.yourpackage.DrawableObject.draw(Graphics), and so on.
Why? The system's designed would make Drawable public, and an interface
so any class could implement it regardless of constraints on its supercla=
ss.
What if I want to draw something I didn't wrote, and whose author
didn't know about my Drawable interface?
Instead in
Lisp I can have
(draw object graphics) and stop - if I want to draw a new kind of
object, I'll write the appropriate method for the draw generic
function.
The cost of having this is that you can change someone else's code, and
even are encouraged to. If they didn't make their class Drawable, why,
you'll just do it for them!
Sure, and what's the problem? I don't change their code, I write new
code which happens to use their class.
[snip]
In Java I really put MY method in the dispatch table of YOUR
superclass.
Not explicitly! And not really at all; the classloader builds up a
dispatch table at runtime.
The classloader does it for you then. The effect is the same.
This is the analogy I'm making.
And I'm telling you, it doesn't quite work.
Adding a subclass in Java that overrides the method IS
EXACTLY LIKE adding a method in Lisp specialized on the subclass. It's
the very same thing.
NO, IT ISN'T! If you still don't understand why I'm afraid you never
will. It's time to drop this line of debate.
For the last time:
--- Lisp ---
(defgeneric f (x))
(defclass c () ())
(defmethod f ((x c)) 'default-value)
BEFORE adding a method for class d:
(f (make-instance 'c)) ==> DEFAULT-VALUE
AFTER
(defclass d (c) ())
(defmethod f ((x d)) 'ok)
(f (make-instance 'd)) ==> OK
(note that the class name D can be in MY package while the name of the
generic function F is in YOURS)
--- Java ---
BEFORE
class C {
String f() {
return "DefaultValue";
}
}
C c = new C();
System.out.println(c.f()); //Prints "DefaultValue"
AFTER
class D extends C {
String f() {
return "OK!!!";
}
}
C c = new D();
System.out.println(c.f()); //Prints "OK!!!"
--------------
The only differences are that, in Lisp,
1. you can define the new method after the class and not necessarily
together with it,
2. you have multiple dispatch, but in this example it is indifferent
since the argument is only one.
The generic function is not changed any more than the abstract clas=
s
is.
Sure it is. The abstract class still contains exactly the same metho=
ds.
The generic function contains new ones. Viewing both as lists, one g=
rew
and one didn't.
Viewing one as a list and the other as a tree (class hierarchy)
A simple strategy: when an apples-to-apples comparison makes your side
look bad, rebut by comparing apples to oranges instead!
imho my comparison is more correct than yours.
Don't be confused by the name "method", which means a different thing
in CL than in Java. A lisp method is a particular specialization of a
generic function: a generic function having one more method in Lisp is
like a method having one more override in Java.
I once knew a guy who was of the opinion that the earth was flat.
LOL.
#: is read syntax that makes the symbol not being interned in any
package.
"Read syntax"?
Yep. An instruction for the Lisp reader.
Can't your register custom protocol handlers? If you can't, then Java
really sucks! :D
Of course you can,
Ok, that's good.
[snipped some tangential rant about things not in Java's standard
library]
Maybe that's the reason I'm using, and sometimes contributing to, a
Lisp implementation running on the JVM... :)
Clojure?
[calls me a liar]
HAHAHAHAHA! How is the sentence "No, ABCL" calling you a liar?!? We're
going into total madness here, boy! I'm a really stubborn guy, as the
poor people reading our posts have noticed (well, those who haven't
still put us in their killfile), but even I am getting tired!