Re: Seeking computer-programming job (Sunnyvale, CA)

[Seamus MacRae]

Why would I do the exact same thing

To make a fair comparison that would actually support your point?

Of course, "why would you NOT do the exact same thing?" might well be
answered with "to AVOID a fair comparison that would actually support
SEAMUS'S point".

languages I don't use

If you don't use Java what's your purpose for participating in a Java
vs. Lisp debate?

This remark does not seem to be relevant.

Of course

Except this was in response to, basically, "how does Lisp do import
foo;?". Apparently it was not actually an accurate answer to the posed
question!
That may be because [excuses, excuses]

Are you endeavoring to assist in getting to the truth of the matter of
which language has the more efficient syntax for imports, or are you
intentionally muddying the waters?

The former.

Fine job so far.

Well, OK, then.


your logic is flawless

Thanks. I try.

 

[Seamus MacRae]

Or

Or nothing. It was an intentional and dishonest misquotation of me that
took one of my comments out of context.

So clearly, in fact, that my change did nothing to obscure that fact.

In other words, you cocked it up!

Your lucid writing
Thanks

almost makes up for your hypocrisy and willful ignorance.

But no thanks. None of that's true of course.

Well, if you insist!

I'll hold you to that.

 

[Seamus MacRae]

there is nothing for you to have or not have.

"A Lisp text"?

[trimmed some condescending fluff with no meaningful substance]

There is no case to present. I am not trying to convert anyone.

Then you must have made a wrong turn somewhere. This is the
converting-Lispers-to-Java-and-vice-versa place. You may have been
looking for the ordinary-Java-discussions place, which is thataway, or
the ordinary-Lisp-discussions place, which is THATaway.

I only wish to provide the necessary information back by the appropriate
references to reduce the confusion about the behavior of Common Lisp.

You can do that without involving me. I'd suggest starting with
gugamilare, he's the one that's most frequently been contradicted by one
or more of the others, so he's probably the most confused.

 

[Adlai]

The ones that know about numbers, strings, symbols, cons cells,
functions, macros, and very little else*. You know -- Lisp compilers!

uh...
First of all, Lisp has multidimensional arrays. Strings and bit-
vectors are special cases of the more general array type, which has
been mentioned in this thread already.

Secondly, not all Lisp compilers are the same. The halfway-decent ones
have CLOS built in -- in other words, it's implemented much more
efficiently and natively than the original CLOS libraries.

Have some self respect and do your research before you make a fool of
yourself again.

 

[Seamus MacRae]

uh...
First of all, Lisp has multidimensional arrays. Strings and bit-
vectors are special cases of the more general array type, which has
been mentioned in this thread already.

Yes, but the most frequently encountered example is the string, so I
said "strings".

Secondly, not all Lisp compilers are the same. The halfway-decent ones
have CLOS built in -- in other words, it's implemented much more
efficiently and natively than the original CLOS libraries.

But to be standards-compliant, it must behave semantically (if not
speed-wise or memory-consumption-wise) identically to a basic,
bog-standard Lisp compiler and separate CLOS library. And then it can't
actually do anything else with CLOS-related knowledge BUT optimize.

Have some self respect and do your research before you make a fool of
yourself again.

This vicious personal attack has no business being here. It does not
advance your case for Lisp over Java nor does it accomplish any other
worthwhile goal, unless you consider alienating people to be a
worthwhile goal.

 

[Jerry Gerrone]

Seamus MacRae and Series Expansion are proving themselves to be
[numerous insults deleted]

Based on his IP address then Series Expansion is twisted alias Paul Derbyshire.

As explained previously, I find it necessary to assume that all
insults aimed at "Paul Derbyshire" here are actually intended for me,
and respond in both of our defense. To set the record straight:

* I am not Paul.
* None of the nasty things that you have said or implied are
true of me.
* I don't know whether the insults are true of Paul, but I
very much doubt that he'd appreciate you insulting him behind
his back.

 

[Thomas M. Hermann]

"A Lisp text"?

A - indefinite article : not any particular or certain one of a
class or group.
Lisp - programming language : Common Lisp (sorry for not being
specific)
text - noun : the main body of matter in a manuscript, book,
newspaper, etc., as distinguished from notes, appendices, headings,
illustrations, etc.

So, what I'm recommending is that you reference the text in one or
many of the books, online or otherwise, covering the topic of the
Common Lisp programming language rather than obtaining the
information, of unknown quality, from a usenet thread. Furthermore, I
erred in only recommending the text, I also highly recommend looking
at the notes, appendices, headings, illustrations and any other
information contained in the books.

[trimmed some condescending fluff with no meaningful substance]

There is no case to present. I am not trying to convert anyone.

Then you must have made a wrong turn somewhere. This is the
converting-Lispers-to-Java-and-vice-versa place. You may have been
looking for the ordinary-Java-discussions place, which is thataway, or
the ordinary-Lisp-discussions place, which is THATaway.

But there is no one to convert. Studying Java and studying Lisp are
not exclusive activities. Studying programming languages is not a zero
sum game.

You can do that without involving me. I'd suggest starting with
gugamilare, he's the one that's most frequently been contradicted by one
or more of the others, so he's probably the most confused.

Whether or not you are involved in the discussion is not within my
control.

Hope that helps,

Tom

 

[gugamilare]

I don't know which Lisp you tried, but it must be a very bad one.

uh...
First of all, Lisp has multidimensional arrays. Strings and bit-
vectors are special cases of the more general array type, which has
been mentioned in this thread already.

You still have forgotten to mention hash-tables, functions,
conditions, structures, pathnames, many kinds of streams, classes,
methods, generic functions (yes, those are Lisp objects as well), and
implementation-specific types like foreign data, sockets, gray-
streams, locks, threads, ...

http://www.lispworks.com/documentation/HyperSpec/Body/04_bc.htm

 

[jborder]

I have posted no misguided nonsense. On the other hand, you have so far
devoted all three of your posts to this thread to exactly that.

The word "nonsense" is justified because [insult] and you have not shown
any interest in providing any corroborating evidence (or even a cogent
argument).

Seamus, engage your obviously superior reasoning skills and consider
the following, which you abbreviated to "[insult]":

"...the overwhelming majority of
what you have said appears factually incorrect..."

I wonder whether you characterise the above as:

a) A statement that I believe that much of what you have said is
incorrect.
b) An insult.

Considering your distaste at being misquoted, intentionally or
otherwise, I find this most amusing.

Those are damned lies! I have supplied lots of cogent arguments and the
occasional citation or other form of evidence.

Yes, Seamus, but they were all demonstrated to be wrong.

Certainly, but not to you; you publicly called me several inapplicable
names when you should have known better, and that makes you a liar.

I don't see any such post. Citations please?

Note that I am still not calling you a liar, or even a troll.

Jamie

 

[Adlai]

I don't know which Lisp you tried, but it must be a very bad one.


You still have forgotten to mention hash-tables, functions,
conditions, structures, pathnames, many kinds of streams, classes,
methods, generic functions (yes, those are Lisp objects as well), and
implementation-specific types like foreign data, sockets, gray-
streams, locks, threads, ...

http://www.lispworks.com/documentation/HyperSpec/Body/04_bc.htm

Yeah, but we don't use those anyways because we just party like it's
1969...

I have a feeling that alienating Seamus might be the healthiest thing
for everybody involved. It would save him many of those trips to the
pharmacy for tylenol.

 

[Alessio Stalla]

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 post).
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.
Are they in the same namespace? Yes, because a class creates a
namespace in Java.

What happens is that, while foo is always the same symbol
(com.package.Class.foo), the compiler knows where it names a variable
and where it names a method, and those are two distinct cases, so no
collision ever appears. Lisp works just the same, only the namespace
is not created by a class but by an ad-hoc object, a package. So for
example you can have the symbol foo in package p, which happens to
name a variable and a function, and symbol foo in package q, which is
another symbol, and names a variable and a class.

In your example, though, this combination was used, along with all three
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.

I don't see why not. Storing jpegs as BLOBs in a DB is not unheard-of.

See the parameter name - it's transaction-manager. A jpeg picture is
not a transaction manager, so this fictional method does not make much
sense.

You can have THAT level of encapsulation in C, FFS. (Using or
withholding "extern" and with judicious omissions from the .h file.)

I don't know C enough to comment on this.

But only at the granularity of whole packages. Not single classes or
smaller scales, aside from what Series elsewhere described as the
"natural encapsulation" of functions whereby ordinarily changes to the
function's body that don't change its signature or semantics don't break
code elsewhere in the program.

The "natural encapsulation" is only natural in Java, C++ and languages
with a similar kind of OO. It's not the only possibility. In Lisp, the
natural encapsulation is at the package level; in another language, it
might be at the module level; and these are certainly not all the
possibilities. Each has its pros and cons. I find the Lisp one
convenient *in Lisp* because Lisp has first-class symbols. In Java the
same thing would be messier - it's more natural in Java that classes
create namespaces.

Verb collisions are the issue. So many things will have close methods,
for example. If you use several of them in one area, you'll only be able
to import one and you'll have to FQ the others. Unless of course the
library designer did as someone else recently suggested here and cracked
open his thesaurus. (Yuk.)

Sure, this is a possible problem. I know you probably won't believe
me, but it does not happen frequently; no more than it happens in Java
with two classes of the same name.

This is the flipside to the many-times-more-nouns-than-verbs thing. A
lot of verb collisions occur among a small set of especially
frequently-used verbs. The power-law scaling of word frequencies serves
to amplify the difference of nearly an order of magnitude in the numbers
of nouns vs. verbs.



They have a problem with code readability or something? That reads like
true, a temporary, or, worst, a generic type parameter, not a class name.

T is the canonical way to represent true. Historically it has also
been used to designate the root of the type hierarchy - the type of
all objects - and naturally it has been used to designate the root of
the class hierarchy, too. Don't ask me why. Surely it does no harm

I'll interpret this as "another of the big headaches of CLOS". It sounds
like one of the biggest headaches of Lisp is the sheer amount of stuff,
special forms, &c. that you'd have to learn to be able to read other
peoples' code written in the stuff. OK, perl is much worse, but still.

No comment.

A fantasy example:

(defgeneric print (object medium))

(defmethod print ((object text) (medium terminal)) ...)
(defmethod print ((object text) (medium laser-printer)) ...)

(defmethod print ((object image) (medium terminal)) ...)
(defmethod print ((object image) (medium laser-printer)) ...)

This is easy to express in CLOS, not that easy to express in Java or C+
+ or Python or any other single-dispatch OO system.

Eh, Java has already expressed this and very easily. Look at the Java2D
API. Corresponding to "text" and "image" we have Shape and subclasses,
which can draw themselves onto a Graphics2D (polymorphically). And
Graphics2D is gotten by various means, but is itself a polymorphic class
that knows how to turn turtle-graphics commands using the generic
Graphics2D interface into results on particular media. If you're
prepping a print job you'll draw on one subclass of Graphics2D, if on a
window you'll get another. No terminals though, Java2D is all about
bitmapped graphics.

For your example a Java programmer might make a Printable interface with
a printOn(Medium) method specified. Implementations would call Medium
methods such as outputString(String), toggleBold(), or whatever was
supported. VT100Terminal would send appropriate escape sequences for
things like toggleBold() and the string for outputString(String) to
System.out. LaserPrinter would send suitable printer control commands to
the parallel port.

Then you could have aText.printOn(aVT100), etc.

I don't know what you were hoping to do with images there; error when
the target was a terminal and print on a printer? That might require
Java2D and adding a getGraphics() to Medium, returning null for
VT100Terminal -- an OOB not-available value printOn would check for.
Image might attempt to gracefully degrade showing a Lynx-style "[IMAGE]"
or attempting to cruft up an ASCII-art approximation using some
algorithm or another, or just complain with an exception. Alternatively,
Medium could throw a GraphicsUnsupportedException or similar from
getGraphics() instead of returning null if the target didn't support
graphics.

All of this with single dispatch.

Where I find myself most wanting double dispatch is when there's two
type hierarchies that need some combined operations, but there's no
natural way to orthogonalize the operations. With most forms of drawing
or printing, though, you can turn the document into a series of
primitive operations of some kind at the document end, and implement the
primitive operations on the medium end. The Graphics2D class is a good
one to check out as its API contains such a set of primitive operations.

http://java.sun.com/javase/6/docs/api/java/awt/Graphics2D.html

A lot of the methods are inherited from

http://java.sun.com/javase/6/docs/api/java/awt/Graphics.html

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? I'd have to transform the Chart in an Image first, or write a
drawChart(Chart, Graphics2D) utility method somewhere and use the
drawXXX primitives there. In CLOS, I would simply define a new method
specialized on Chart and Graphics2D, and it would be indistinguishable
from built-in methods that deal with polygons, text, and images.

One option is to arbitrarily make one of the two classes "more
important":

interface Printable {
public void printOn(Medium medium);
}

class Text implements Printable {
  public void printOn(Medium medium) {
    if(medium instanceof Terminal) {
      ...
    } else if(medium instanceof LaserPrinter) {
      ...
    } else {
      throw new IllegalArgumentException("Don't know how to print " +
this + " on " + medium);
    }
  }
}

...same for Image...

Bletcherous. See above for the alternative that avoids switch, enum,
instanceof, or any other similar kludge.

Another option is to concentrate the printing code in a third class:

abstract class Printer {

  public void print(Printable object, Medium medium) {
    if((object instanceof Text) && (medium instanceof Terminal)) {
       ...
    } else ... //you get the idea
  }

Neither option is good imho, since both force you to explicitly code
dispatch tables and manually maintain them - exactly what you DON'T
have to do with CLOS.

Except that a) I just showed how to avoid doing so -- in this case at
least -- in Java, and b) Anonymous C Lisper does exactly that with CLOS
to judge by his one major post containing sample Lisp code.

I'm sorry, but I genuinely think [repeats insults]

Think what you want, but please restrain the urge to blurt out uncivil
things in public. Weren't you taught any manners as a child?

I don't think saying someone is in error about something is insulting
him.

It does not.




Except when you subclass a class, you're making an altered copy in
essence; when you add to a generic method, you're fiddling with the
original, not a copy, and maybe it wasn't "yours".

See above re: MY:frobnobdicate with YOUR:quux.

If I write MY:frobnobdicate specialized on YOUR:quux, I'm not altering
the behavior of MY:frobnobdicate specialized on other objects. I'm
adding a possibility, not changing behavior. If you call
MY:frobnobdicate with MY:quux, the behavior is the same whether I have
defined the YOUR:quux version or not. Although methods are registered
in a "global" place - their generic function - each method is a thing
of its own, much like a derived class is distinct from its base class.
In pseudo-Java:

public abstract class MyGenericFunction<T1, ..., Tn> {
public abstract Object call(T1 arg1, ..., Tn argn);
}

public class MyMethod1 extends MyGenericFunction<my.Foo, ..., my.Bar>
{
public Object call(my.Foo arg1, ..., my.Bar argn) {
...
}
}

public class MyMethod2 extends MyGenericFunction<your.Foo, ...,
your.Bar> {
public Object call(your.Foo arg1, ..., your.Bar argn) {
...
}
}

If I add MyMethod3, the behavior of 1 and 2 does not change, yet I can
get different results from an instance of MyGenericFunction (when it
is an instance of MyMethod3).

Sure it is. The abstract class still contains exactly the same methods.
The generic function contains new ones. Viewing both as lists, one grew
and one didn't.

Viewing one as a list and the other as a tree (class hierarchy), both
grew.

It's a preference that suggests you tend to work alone or on a small
team. Working on a large team results in there's-too-many-ways-to-do-it
being a very real possibility, with everyone doing the same "it"
differently and everyone having to know every single language feature,
however obscure.

there's-only-one-way-and-it-is-not-optimal is a real possibility, too.
But this is OT.

Without the javadocs Java's standard library might plausibly have caused
some trouble of a similar nature by its sheer size. It helps though that
there's generally only one or a few clearly-near-optimum use patterns
for a given job, and that everything (mostly) has descriptive names too.
ListIterator and MessageDigest are names that convey quite a bit about
what they do; defgeneric and #:cl #:foo somewhat less so.

defgeneric DEFines a GENERIC function.
cl is shorthand for common-lisp, and foo... well, it's foo

Which topic came up again; see above.



I'd agree with that assessment. But I didn't say *you specifically* said
Java code looked like vomit. Certainly *one* of you did, though, a few
days ago, and others appeared to hold comparable opinions.


Including especially the things that will fry your coworkers' brains, no
doubt. (Though you can be pretty evil with the reflection API, static
initializers and constructors with side effects, asserts with side
effects, ClassLoader tricks, and so forth.)


Java's library and Common Lisp's object system, I'll bet. But users
don't have to learn the whole library and do have to learn the whole
object system...


Subjective statements like that cannot resolve many of the questions
here; at worst they might fan the flames, though maybe with "Lew"
apparently bowing out of it the worst of those are over.

I actually don't think most people here disagree with my main thesis,
which is that Java and Lisp have relative tradeoffs, with neither
invariably superior to the other. The sticking points all seem to
involve specific things claimed to make Lisp superior at one time or
another by only a handful of the most extreme pro-Lisp partisans, and
why these features don't *actually* do so.

Mind you, I usually refrain from saying something is absolutely
"superior" because there are really many dimensions to be considered,
but I do think Lisp has some key ideas that are superior to what I
find in other languages. And yes, one of them is macros
I also think Java has a lot of nice features which probably many
lispers don't know about. Built-in serialization is one of those, for
example, as is the nice integration of URLs into the language, the
collections framework, ...
Maybe that's the reason I'm using, and sometimes contributing to, a
Lisp implementation running on the JVM...

 

[Kaz Kylheku]

["Followup-To:" header set to comp.lang.lisp.]

Pillsy wrote:
I might, but if I wanted it to inherit from Number, I could certainly
choose to have it inherit from Number. I'm just not sure that's the
way to go from a design standpoint, though admittedly I haven't
thought about the question a whole lot..
Taking it as a given that Complex should be a subtype of Number, how
else would you go about doing it?

Are you asking about implementation strategies about how to add
this ANSI CL feature to Seamus MacRae Imaginary Lisp.

No; there's no such thing as SMIL anyway.

Obviously, there is. It may not be implemented, or fully specified,
but it's whatever Lisp language you are talking about in this thread.

Being a competent engineer and all, you wouldn't be caught dead spewing
nonsense about a language you know nothing about, such as Common Lisp,
right?

I was asking Pillsy to clarify
something that he wrote, and how he would do something. And since you're
not Pillsy, it is very odd for you to jump in at this point.

How do you know I am not Pillsy? Guessing again?

Yes really.


In Lisp? Surely you jest. At base, it has no static types and precious
few dynamic ones (integer, maybe a few other numerics, cons cell,

There is no static type, only type. Static type is simply the situation when a
type is being analyzed or otherwise manipulated prior to run time.

When we use a constant like 42, we don't call that ``static valuing'',
implying that it's a different kind of value from the situation
when some variable x holds 42.

I don't understand ``precious few''. If a language has a precious few types,
but all values have a type, then everything has type, right?
How many types must a language have before it's typed?

My statement ``Originally, everything had type'' was meant in contrast to the
current Common Lisp situation, in which everything has /both/ a type and class.

This is very language specific. An OO language designed from scratch today
might have only a single concept: just class.

string, symbol, nil, and little else).

Disclaimer: I'm writing strictly about Common Lisp (and in this case its
predecessors), not Seamus MacRae Lisp, which I know next to nothing about.

This seems to be checking some programmed-in notion of types, not
compile-time types of any kind.

Why have you chosen to contrast ``programmed-in notion'' against
``compile-time''?

In Common Lisp, the above is an expression, a call to subtypep. The subtypep
function takes two arguments which are types. Types are represented by symbols
(among other things). The symbol number represents the number type, and the
symbol complex represents the complex type.

If this expression is being compiled, then in fact we do have a situation in
which types are known at compile time: they are named right there! This is
actually a constant expression which can be compiled down to the constant T; the
compiler can know that subtypep is a standard CL function, and that it returns
T when applied to these particular arguments.

Anyway, the point was that Lisp has these types in that subtype relationship.

You could program this behavior in any language.

Terrific. An example (e.g. Java) would go a long way here.

Maybe a bit. At the cost of lots of debugging later on, in big enough
systems.

You have asked for evidence when people claim that this isn't a big
problem. Where is your evidence that it is?

In computer programming, a lot of aspects of the behavior of a program
are susceptible to compile-time staging, not only type.

What is your rational justification for being obsessed with doing this with
type?

Type is the simplest, most trivial aspect of a computer program.
Errors in type are among the easiest to debug.

The burden of proof rests on those who claim that any property X of a computer
program should be simplified and staged to compile time.

I have stated it repeatedly. You keep ignoring it.

Pardon me. Would you mind citing a Message-ID of the article containing
this evidence? I can't find it.

Well, there we are. I guess we are now in agreement.

So why am I still apparently only 1/3 of the way through your
interminably long post?

I assure you that the post does terminate. In terms of raw volume, I think you
are winning. I have not posted here nearly as much as you. You're
single-handedly taking on what seems to be at least half a dozen people.

Easy: what would have been caught in seconds at compile time, or even
instantly in the IDE when editing (red squiggly underlines: another
feature untranslatable to a box of pure ASCII), instead isn't caught
until run-time and possibly far from the true location of the error.

State-of-the art static typing systems also locate errors sometimes
far from the true location. You might want to Google for "Hindley-Milner"
to discover how typing is done in post-deluvial static languages.

Seconds of debugging becomes minutes at best, hours at worst.

Say the downside is 30 minutes.

Now note that type errors are an estimated 30% of bugs.

Aha, numbers. Where do these numbers come from? Can you cite your source?

What exactly is a type error? If, in a static language, two declarations do not
match, is this considered a type error, and is that counted toward the 30%
statistic?

Would we have that type error in a dynamic language?

A bit more up-front keyboard typing.

Do you think that every dynamic program can become a static one,
with only a ``bit'' of extra keyboarding?

How much is a bit? 10% more code?

Maybe more thought as to what
should be what and going where during design and coding, but that will
pay off as an investment down the line.

How about allowing the progrm to be easily changed with respect to
changing requirements? The world is a changing place.

There's a risk you won't be able to mischievously sneak a Float into a
group of Strings...


No, I am not. I am asserting that they balance out in favor of static
typing.

Based on what? Religious faith?

Then get some and post it.

You first.

This is the kind of worthless anecdotal "evidence" that all too many
people mistake for the real thing.

It's better claims from people who have no experience with dynamic typing, and
are purely guessing.

You'll also find that all of Java's "de facto macros" lack multiple use
of any argument, and so don't run into the variable capture/global
variable/multiple evalaution trichotomy.'

Yes, well these de-facto macros have to take that into account in their code
generation. The Java compiler, when faced with synchronized (expr) ... has to
generate code which evaluates expr to an object reference, and then store that
reference in some hidden variable. Then places in the expanded code which
require the value of the expression refer to the hidden variable; they do not
re-evaluate the original expr.

In macro systems, this is addressed in two ways. In the Scheme language,
which is a Lisp dialect, there are hygienic macros in which these issues are
taken care of automatically. Hygienic macros are cool, but some non-hygienic
things are awkward to do in them. In Common Lisp macros, hygiene is implemented
by the macro writer, in various ways.

A common strategy is to generate some unique symbols which are used to
name hidden variables.

Suppose we have a three-function API for locks:

(monitor-enter m) ;; enter monitor m
(monitor-leave m) ;; leave monitor m
(ensure-monitor o) ;; ensure object o has a monitor and return it

In Lisp we have the unwind-protect construct for running cleanup statements
no matter how an expression terminates; we will use this in the expansion.

Given the expression

(synchronized obj s1 s2 s3)

We want to generate code along these lines:

(let* ((hidden-obj obj)
(hidden-mon (ensure-monitor hidden-obj)))
(unwind-protect
(progn (monitor-enter hidden-mon)
s1 s2 s3)
(monitor-leave hidden-mon)))

Of course we won't call the hidden variables by these names; we will let the
compiler name them by calling the gensym function at macro-expansion time.

(defmacro synchronized (obj &body statements)
(let ((obj-var (gensym))
(mon-var (gensym)))
`(let* ((,obj-var ,obj)
(,mon-var (ensure-monitor ,obj-var)))
(unwind-protect
(progn (monitor-enter ,mon-var))
,@statements)
(monitor-leave ,mon-var))))

Expansion test:

[1]> (macroexpand '(synchronized a b c d))
(LET* ((#:G3131 A)
(#:G3132 (ENSURE-MONITOR #:G3131)))
(UNWIND-PROTECT (PROGN (MONITOR-ENTER #:G3132)) B C D)
(MONITOR-LEAVE #:G3132))

Looks good. So you will find that properly written Lisp macros share
this property of the properly written Java compiler features: no
unexpected capture, or multiple evaluation.

Oh, and by the way, there is one more piece to the hygiene puzzle. Note how
our macro expands to a body of code that uses some functions and operators.
There could be a problem if a function like ensure-monitor is locally
redefined. Typically this is dealt with using packages. It would really be,
say, (thread::ensure-monitor ...). Only you would probably not have to write
the explicit thread:: qualification because your defmacro would be in a file
where the thread package is in effect. Further, Conforming Lisp programs are
not allowed to redefine standard functions and operators like unwind-protect
and progn.

C, not assembly.

What's the difference, in this context? Can your CPU run assembly?

I can feed either assembly or C to a compiler front end driver and get an
object file.

You're jumping to unwarranted conclusions about me.

Is that so? I haven't ever had version control problems with yacc or bison files.
So the problem must be on your end. Somewhere between the keyboard and chair.

I don't have serious
problems with Bison and version control.

I don't have problems with Bison and version control, period.

I do anticipate there could be
serious problems with Lisp code rewriting the (foo foo) bits of itself
and version control.

Maybe in Seamus MacRae Lisp, if you don't design it properly.

If that is supposed to be a statement about Common Lisp, then it's a very
poor, inaccurate guess.

The intermediate results of macroexpansion are not written to a file.

There isn't any more of a version control problem with (foo foo) rewriting
itself than there is a problem in Java with synchronized (foo) { bar; }
rewriting itself.

I was shown a screenshot and told by a known hostile entity and probable
liar that it was emacs, and the screenshot showed something that
resembled emacs the way the Eiffel Tower resembles a tea saucer.

Funny, I looked at the PNG and saw only Emacs.

I didn't know Slime could do embedded graphics. I.e. evaluate a Lisp
expression, and the resulting value is a graphic. Cool.

I'm not an Emacs user, but I believe the PNG.

I find that particularly unlikely to be true. I'm adding you to my list
of "probable liars" in this thread.

What is a probable liar? Someone who offends you with facts that
don't agree with your pre-conceived notions?

Wouldn't it be easier to maintain a list of non-liars?

If you want to list probable liars one by one, you will eventually
need a few gigabytes of space to represent most of the entire world.

Just assume everyone is a liar. And, whatever you do, do not Google
up for a single fact to confirm or refute anything. The results of
search engines are all lies also.

I'm sorry, but I don't know of any "Seamus MacRae Lisp".

Right; I will substitute the proper name as soon as you share it with us.

 

[Kaz Kylheku]

Never heard of it, sorry. I thought we were discussing Common Lisp anyway.

You don't appear to know anything about Common Lisp, so that can't possibly be
the case.

How much code have you written in Common Lisp? What reference materials have
you studied? How familiar are you with the HTML-ized ANSI standard of
Common Lisp known as the CLHS (Common Lisp Hyper-Spec?).

How confident are you you could pass a closed-book newbie-level
exam in Common Lisp?

People are to interpret what you are saying as being about Common Lisp, you
look like a complete twit who posts whatever made-up nonsense that pops
into his head, presenting it as a fact.

So you may want to retract your claim that you are discussing Common Lisp.

 

[Kaz Kylheku]

Don't have one, sorry.

You don't have Internet access? How do you post?

There are a number of free books about Common Lisp that you can download.

(Your antedeluvial browser might blow up on a PDF, mind you).

Moreover, the HTML-ized form of the ANSI CL standard, courtesy of Kent Pitman,
is available for download for local installation, as well as hosted by several
sites for online reading.

I don't have any Java book on my shelf, but before posting anything about Java,
I check my facts in _The Java Language Specification_ and other sources
online.

My point stands: if you guys can't be arsed to get your act together and
present your case MUCH better, you can hardly complain if you find you
don't manage to acquire many new converts or if you find your various
errors or disagreements being nitpicked by people you'd previously flamed.

Not everyone cares about converts. The fewer people program in Lisp, the
better.

Idiots of the world, stick to wearing your bear skins and carving with stone
knives.

Use (as via the :use clause in defpackage) is not import. Package use
doesn't change package membership. Symbol import does.

Visibility does mean that that if package foo has an external symbol sym, then
you can now use my-package::sym. But you cannot use my-package:sym. The
accessibility situation does not cause the symbol to be external in my-package.
The effect is as if my-package had an internal symbol called sym.
My-package can, however, re-export the symbol:

(defpackage :my-package
use :foo) ;; provides SYM
export :sym) ;; re-export SYM
)

Now we can write my-package:sym.

But Alessio said "declares that all symbols from packages x and y are
also in package my-package" ...

The facts, from the Common Lisp HyperSpec are this: the use of one package by
another causes the exported symbols of the used package to be /accessible/
through the one which is using it. A symbol import is different; it actually
sticks a symbol into a package. The same symbol object can be imported into
more than one package. It is then more than just /accessible/ in all those
packages; it is said to be /present/ in all of them. One of the packages
where a symbol is present may be its home package. This is the package that is
returned when we ask a symbol what its package is using the symbol-package
function. Symbols which have no home package are printed with a special
notation (the #: prefix).

Not all people in comp.lang.lisp are language lawyers, let alone about the
intricacy of packages.

 

[Kaz Kylheku]

Don't have one, sorry.

You don't have Internet access? How do you post?

There are a number of free books about Common Lisp that you can download.

(Your antedeluvial browser might blow up on a PDF, mind you).

Moreover, the HTML-ized form of the ANSI CL standard, courtesy of Kent Pitman,
is available for download for local installation, as well as hosted by several
sites for online reading.

I don't have any Java book on my shelf, but before posting anything about Java,
I check my facts in _The Java Language Specification_ and other sources
online.

My point stands: if you guys can't be arsed to get your act together and
present your case MUCH better, you can hardly complain if you find you
don't manage to acquire many new converts or if you find your various
errors or disagreements being nitpicked by people you'd previously flamed.

Not everyone cares about converts. The fewer people program in Lisp, the
better.

Idiots of the world, stick to wearing your bear skins and carving with stone
knives.

Use (as via the :use clause in defpackage) is not import. Package use
doesn't change package membership. Symbol import does.

Visibility does mean that that if package foo has an external symbol sym, then
you can now use my-package::sym. But you cannot use my-package:sym. The
accessibility situation does not cause the symbol to be external in my-package.
The effect is as if my-package had an internal symbol called sym.
My-package can, however, re-export the symbol:

(defpackage :my-package
use :foo) ;; provides SYM
export :sym) ;; re-export SYM
)

Now we can write my-package:sym.

But Alessio said "declares that all symbols from packages x and y are
also in package my-package" ...

The facts, from the Common Lisp HyperSpec are this: the use of one package by
another causes the exported symbols of the used package to be /accessible/
through the one which is using it. A symbol import is different; it actually
sticks a symbol into a package. The same symbol object can be imported into
more than one package. It is then more than just /accessible/ in all those
packages; it is said to be /present/ in all of them. One of the packages
where a symbol is present may be its home package. This is the package that is
returned when we ask a symbol what its package is using the symbol-package
function. Symbols which have no home package are printed with a special
notation (the #: prefix).

Not all people in comp.lang.lisp are language lawyers, let alone about the
intricacy of packages.

 

[anonymous.c.lisper]

Yes, but the most frequently encountered example is the string, so I
said "strings".

Please stop these vicious personal attacks!

But to be standards-compliant, it must behave semantically (if not
speed-wise or memory-consumption-wise) identically to a basic,
bog-standard Lisp compiler and separate CLOS library. And then it can't
actually do anything else with CLOS-related knowledge BUT optimize.

What would it do other than optimize?
There's this thing called the meta object protocol that is kind of
neat.
I bet you could implement Java.

This vicious personal attack has no business being here. It does not
advance your case for Lisp over Java nor does it accomplish any other
worthwhile goal, unless you consider alienating people to be a
worthwhile goal.

Seriously I think you need to declare the troll accomplished and find
someone new to bait... this is getting old.

No one believes that you actually consider that to be a /vicious/
personal attack.

I'm quite please that I got you all to say frobnobdicate over and
over, however.

Gave me a chuckle, anyway..

 

[Kaz Kylheku]

You're right though about the productivity of this debate. It's like
evolutionists vs. creationists: one side has logic and evidence on its
side, the other unshakable faith, and neither will budge. We'll never
give up our logic and evidence and apparently you'll never give up
your faith. And since there are no important public policy issues at
stake, your continuing to argue is pointless.

It's ironic, really, that when you write something which seems to make
sense, you have got it exactly backwards: You are obviously the one
arguing from faith and faulty reasoning. [& further personal attacks]

Who are you, and what is the point of this unprovoked drive-by flaming?

You should ask yourself ``what am I doing to provoke drive-by flaming''?

I personally don't have a problem with drive-by flaming; if you keep
experiencing drive-by flaming, the common denominator in all such
situations is /you/.

 

[Pillsy]

Pillsy wrote: [...]

Your lucid writing

Thanks

almost makes up for your hypocrisy and willful ignorance.

But no thanks. None of that's true of course.

OK, fine: your crappy writing does nothing to make up for your
hypocrisy and willful ignorance.

Feel free to have the last word.

Later,
Pillsy

 

[Arne Vajhøj]

Pillsy wrote: [...]

Your lucid writing

Thanks

almost makes up for your hypocrisy and willful ignorance.

But no thanks. None of that's true of course.

OK, fine: your crappy writing does nothing to make up for your
hypocrisy and willful ignorance.

Arne

 

[Arne Vajhøj]

As explained previously, I find it necessary to assume that all
insults aimed at "Paul Derbyshire" here are actually intended for me,
and respond in both of our defense. To set the record straight:

* I am not Paul.
* None of the nasty things that you have said or implied are
true of me.
* I don't know whether the insults are true of Paul, but I
very much doubt that he'd appreciate you insulting him behind
his back.

So you consider yourself insulted ny being accused of being
Series Expansion.

I can understand that !



Arne