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

[Lew]

But can you debug Java code in [emacs]?

You bet it can. I don't now how because I don't program in java [sic], but
Emacs has support for many languages, including Java.

Can anyone point me to any documentation as to how? I've been a big fan of
emacs for a lot of years, and its inability to debug Java has been the only
shortcoming I've encountered with it to date.

I've looked for instructions before, but had no luck. I miss the days when I
could do gcc compiles from emacs and debug via its gdb interface. I gather
from what you're telling me that the emacs gurus have sussed out how to tie
emacs into the JVM, a remarkable achievement indeed. This is great; I can
start using emacs for my Java development once I get this information.

Please do not quote sigs.

 

[John B. Matthews]

Limiting the length to 0x1FFFFFFF (~0.5 GiB) in gets() eliminates
the warning:

[...]
Great. I will use this limit in filGets().

I am unsure where this limit comes from. I'd have thought to change it
in chk_all.sd7, but you may be right to constrain the value to some
maximum in filGets().

[...]

Regarding the warnings: For some reason your C compiler is not
capable to evaluate the expression

sizeof(offsettype) == 8

at compile time.

I'm not seeing this in other contexts, but I have not read the seed7
sources closely. FWIW, I get different warnings from gcc v 4.3.4.

So the C compiler is complaining about things in unreachable code.
The other warnings can be avoided with casts. I will try to remove
this warnings.

Excellent. Ping me when it's time to try a new Mac OS build.

BTW: Thank you for the list of warnings you sent by mail. I will
take a closer look at the list, but at first sight I consider the
warnings harmless. I will try to reduce them nevertheless.

I defer to your knowledge of the program.

[...]

I still have some questions:

Do you have other ideas regarding Seed7?

You might consider adding the SourceForge logo to your web page and
using one of their source code management services; I like svn:

Is the documentation sufficient?

I found build instructions in "read_me" and the fine manual & FAQ in
"doc". I'd say more than sufficient.

 

[gugamilare]

How rude.


Let me guess: using macros to try to graft on some sort of poor-man's
type-checking?

Not poor-man's, but very precise and powerful type-derivation and type-
checking. Not having to worry about variable types is a bless. Having
a compiler that detects the type of the variable by your code is also
a bless. Having the option to tune optimization by declaring types
(specially where the compiler gives you the hints) is also a bless.

That seems to cement the case for static vs. dynamic typing -- users
of dynamic languages end up finding ways to emulate static typing!

The other way around is also true, once in a while static typing
languages encapsulate more than one type in a box. Sometimes they just
write the same code twice - once for each defined type.

We only "emulate" static typing in the places that need speed, the so
called bottlenecks.

Someone call the doctor -- Adlai has anaphoric macros!

Er -- what are anaphoric macros?

Useful tool? Even if so, variable capture is clearly a dual-edged
sword. Lisp macros? Dual-edged Swiss-army knife, maybe.

They are not when the user knows about them. I believe this amount of
control just confuses you, but it is really not that big deal.

Global variables for fun and profit! I bet you guys get ...
*interesting* scaling problems with large projects.

The binding is local to the use of the if form, not global.

 

[Lew]

Well , I did warn in [1] that the argument and counterargument
have been brought up before , years ago , on comp.lang.python so
you shouldn't be surprised if you encounter here it as well. I
think [1] appeared before you started commenting on macros.

What's this [1] shit? Some creative sort of pseudo-pronoun?

It's obvious to the rest of us, without resorting to potty-mouthedness. Use
of a reference to a footnote as a stand-in for the contents of the footnote is
a long-established practice among the literate.

 

[Series Expansion]

Yeah, and you read the ASCII string and do syntactic analysis on it!

No, YOU read the ASCII string and do syntactic analysis on it. I
prefer to have tools that will do that sort of crap for me.

Emacs has this power for two reasons (that I know of off the top of my
head):
1) It's written in a dialect of Lisp

To you guys, Lisp is like some magic elixir that grants lifelike
behavior and extraordinary properties to anything infused with it,
isn't it?

Well, I've got news for you. Here in the real world, there ain't no
silver bullet. No philosopher's stone. No magic spell a wizard can
cast to make brooms come to life and carry water or whatever. Instead,
we have this thing called "engineering". We actually have to figure
something out and then build it to run on ordinary electricity or
gasoline. And if something is impossible, it just plain won't work.

READ MY DETAILED POST ABOUT SLIME PLEASE BEFORE SPEWING FORTH MORE
IGNORANCE UNTO THE NETS!

READ EMILY POST PLEASE BEFORE SPEWING FORTH MORE PERSONAL ATTACKS UNTO
THE NETS!

Look, when you debug a macro expansion, YOU DON'T EXPAND IT INTO THE
SOURCE CODE.

Apparently, gugamilare disagrees.

When you test a macro using the MACROEXPAND form, you evaluate that
separately, in a Lisp prompt, or in a separate prompt opened by slime,
the way a normal IDE does.

Prompts are so 1985. And wouldn't you need an MDI window system to
have anywhere else for it to expand into BESIDES your source file?

Defining dependencies is a) a piece of cake

Yeah, yeah, that's what they all say.

and b) something that macros do for you.

Fan-bloody-tastic. You know that can't possibly work reliably, right?
It's one thing if the dependency analysis is done by automation when
it's an external tool like automake. It's another if it's done by part
of the same code base undergoing the dependency analysis. Now, the
dependency analysis itself might affect the dependencies, which is
precisely the kind of headache I was alluding to earlier with self-
referentiality.

That's why we've got SLIME, a huge package of editor customizations
that sets up Emacs into a powerful Lisp IDE.

SLIME must be magic, then, if it can grant the editor the knowledge
that SuperVGA has been invented from *inside its internal script
interpreter* without even a droplet of native C code to actually talk
to the display hardware. It's amazing! It's fantastic! It makes
Windows Plug'n'Pray obsolete! It's ... slime!

Well, it's that or someone was wrong about SLIME being written
entirely in an editor's scripting language, or you're wrong about what
it can do, or (least plausible of all) someone's definition of
"powerful IDE" allows the possibility of one being a prompt-driven
terminal-mode archaism from the 80s.

My personal theory is that someone's looking at all of this stuff
through rose-colored glasses.

Read my post here if you haven't already, so that you understand what you're talking about...

I don't tend to comply with requests that are asked of me as rudely as
that.

Man, give the guy a break. He miscommunicated to you, and now you're
just deliberately sticking to a misinterpretation to wave in our face,
instead of trying to understand our explanations.

Another personal attack, this time accusing me of lacking integrity
and intellectual honesty? Wow, you must have completely run out of
rational arguments in favor of dynamic typing if the only shots left
in your quiver are this lame.

Uh, actually, they did hack the server while it was live.

No, the term "releases" indicates they followed a standard development
model, perhaps somewhat accelerated but otherwise typical, rather than
going the "no plans, no prototype, no backup" route.

Somebody posted this link earlier, maybe you missed it.http://www.flownet..com/gat/jpl-lisp.html

I quoted and responded to it right there, you dipshit!

Here's a quote from that page (under the heading "1994 - 2000": Remote
Agent):

"""Remote Agent controlled DS1 for two days in May of 1999. During
that time we were able to debug and fix a race condition that had not
shown up during ground testing. (Debugging a program running on a
$100M piece of hardware that is 100 million miles away is an
interesting experience. Having a read-eval-print loop running on the
spacecraft proved invaluable in finding and fixing the problem."""

They used it to perform remote diagnostics, and subsequently to upload
a patch. Nothing is implied about how that patch was developed and
tested in the meantime. Consider though that experimenting with the
live version on board the spacecraft, were this to shut it down or
render it unable to receive or transmit signals, would have meant the
loss of the multi-million-dollar probe. It stands to reason that they
did nothing to modify the probe's code without extensive testing on
the ground first.

Is it possible to scream "Lisp saved our asses" more loudly than that
does!?

They could have launched it hosting a JVM with an attached debugger
and still done what it's implied they did.

Please read up on SLIME, Emacs, CLOS, and Common Lisp Macros before
you continue posting ignorance!

Please read up on etiquette, polite society, civilization, and Emily
Post before you continue posting personal attacks!

 

[thomas.mertes]

Warnings are never harmless. If they were harmless, there wouldn't be any
warnings.

I don't consider all warnings as harmless. I was referring to
specific warnings which were mailed by John B. Matthews. When
compiling with gcc (which is also used also under Mac OS X) I use
the following options to get as much warnings as possible:

-Wall -Wstrict-prototypes -Winline -Wconversion
-Wshadow -Wpointer-arith

I could have used the strategy of many other projects: Just specify
a lower warning level. But I prefer to see as much warnings as
possible. Exactly for the reason you mention below (warnings may
be a hint for real errors). Examples of warnings happening during
the compilation of the Seed7 (hi) interpreter:

drwlib.c:253: warning: passing argument 5 of 'drwArc' as 'float'
rather than 'double' due to prototype

This warnings happens every time the formal and the actual parameter
are just float instead of double. In total there are 20 such
warnings.

identutl.c:107: warning: pointer targets in passing argument 1 of
'strlen' differ in signedness

This warning happens when a functions with a formal 'char *'
parameter gets an actual parameter of type 'unsigned char *'.
In total there are 16 such warnings.

ref_data.c:838: warning: pointer targets in assignment differ in
signedness

This warning happens when a 'char *' expression is assigned to a
'unsigned char *' variable or vice versa. In total there are 5 such
warnings.

I've seen major bugs, in C programs and other languages, that were revealed
"only" through warnings.

The attitude that "warnings are harmless" is a major problem in the software
industry and one that needs to be stomped hard. It's nothing but
carelessness. Well, laziness. Negligence, regardless.

I agree. OTOH I am not sure that it is possible to get rid of all
warnings. It would be nice to get your help to examine all warnings.

To see a list of errors just download and compile the Seed7 package.
A place in the (soon to be created) hall of fame is the reward.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

 

[gugamilare]

The first post in this thread was some guy whining that he couldn't
get a job. You'll forgive me if I fail to see how that's relevant to
the Great Lisp vs. Java Debate of 2009.

What the hell of a good point you have (ironic). Should I look for
unemployed Java programmers? I bet there are some.

This is not Lisp vs. Java debate. We are not attacking Java at all,
because we are not the trolls here. This is more a "Java programmers
that don't understand and never programmed in Lisp before rudely,
pointlessly and with very weak arguments attacking Lisp" debate. Give
me one reference to someone here saying that Java is a bad language,
and I am done talking. Maybe someone pointed out one or two
deficiencies of Java, but this is not untrue for Lisp as well - Lisp
is not perfect, you know, but it IS a great language, and you will
only understand that if you learn it. You Javaers are the ones
treating us like if we are a bunch of amateurs who don't know how to
program.

We over here are just showing why you are wrong, but this is a
difficult task since for every argument we make, you bring the very
same feature to the world of Java - where things are very different
from the world of Lisp - and argument in your world why this feature
is a bad thing. I agree, these features would be bad in the JAVA
language, but they are not an issue in the CL language, and you MUST
learn CL (or at least a simpler Lisp dialect like scheme) to
understand why. Java and CL are very, very, very different languages.
If some feature would be an issue in the Java world, it does not
necessarily mean that it would be a bad thing in the Lisp world. The
opposite might as well be true, there may be some Java features that
can't be transported to Lisp because of the way Java / Lisp is, no
arguments here.

 

[Series Expansion]

So in other words they have reduced their use and adopted a
collection of guidelines for macro usage which bring the danger
down to an acceptable level.

While you lot apparently just use them in a gung-ho manner until the
sky falls down on you.

And they consider them one of the parts
of the language to be most proud of.

I'm sure Ted Bundy's mother was proud of him, even for a while after
everyone else started telling her he was a bad seed.

Yes

macros only interact with the code which uses them in much the
same way that functions only interact with code which uses them.

The problem is that "the code which uses them" includes any code that
contains the text that triggers the macro and that occurs after the
macro in evaluation by the compiler.

I expect you would get many warnings about assigning integer to
pointer without a cast.

That's still compiling, and it can be made silent easily enough:

#define malloc(x) ((void *)1)

C is not type safe because it has casts

It's type safe compared to Lisp! Though Java is "type safer" than it
is since its casts are tightly regulated, and mis-casts produce a
clean run-time error.

but it's besides the point. Imagine that C didn't have macros.
You go on and change the definition of malloc()...

Still not getting it, I see. To change the definition of malloc() one
would edit the source file containing malloc(). Whereas that macro
could be stuck pretty much anywhere and blow things up. Locality of
side effects of code changes is destroyed by macros.

Obviously yes so why is it that macros specifically cause the
problem?

The problem with macros that I've been getting it is their inherent
ability to alter the behavior of far-away code from pretty much
anywhere. A function has to be intentionally invoked by some code to
have effect there; a macro has to be coded to operate ON some other
code to have effect there. It's easy to whip up a C macro that affects
all the code that uses strlen() or all the code that uses char *
pointers or turn all the code's floats into doubles. Some of these
uses might be useful. All of them are potential maintenance headaches,
since

1. Someone reading the affected code might assume it does what it
says at face value, and the macro changed that;
2. Even if they know, or suspect, otherwise, finding all the macros
that potentially alter the behavior of a particular bit of code
is an exercise in haystack-needle-finding.

Lisp macros apparently are slightly more limited, having to take the
form of function calls rather than arbitrary code fragments. However,
my example of a destructive C macro was intentionally chosen to adhere
to that restriction and show that that restriction does not
significantly reduce the hazard. At least if you suspect some function
has been replaced or altered by a macro, you can search on the
function's name and find any such macro since the name has to be the
same. Of course, if you suspect some chunk of code has been affected
by a macro, the whole code base must be searched for any macros whose
names match any function names occurring in the affected chunk, which
might mean searching several thousand files for each of several dozen
different names.

It's Tylenol time!

Apart from that you give an example where you use a macro in a
silly manner.

It's a bit contrived, but it's not outlandish to imagine it resulting
from an accidental typo hitting "#define mallow" or something.

You cannot extrapolate from that to when you use
macros in a thoughtful manner.

Typos are non-thoughtful more or less by definition.

Anywhere the macro is used just like functions. Look, macros are
also functions whose input and output is Lisp code. You seem to
think that if a function's input and output is anything other
than code then it's ok but when the input and output is code
then you reach a whole new level of danger.

No, I think that when an innocent-looking function call may have been
redefined far from either the call site or the (nominal) site of that
function's definition, then code maintenance becomes a hell of a lot
harder.

It's interesting but I'm not sure it's relevant.

That's the hallmark of faith-based belief systems: empirical
statistics are irrelevant.

There's no point in arguing further with you, then; it's a corollary
that arguing against someone's faith tends to be useless, as compared
to arguing against someone's erroneous beliefs that are not faith-
based.

Take you for example: you have strong opinions about macros but
I bet you've never written a single Lisp macro.

I've written lots of macros, though, in a variety of places and
contexts.

May I suggest reading chapter 7 of "Practical Common Lisp"?

Don't have it and can't be arsed to blow $40 on something I'll
probably never use, sorry.

 

[Series Expansion]

I'm sorry, I was assuming that you could read

I probably shouldn't even dignify this post with a response, after
that jab, but what the hey.

SLIME adding power!

... to old (not) useless Emacs!

Allah akbar!

Hallowed are the Ori!

Long live the king!

For ever and ever, amen!

Emotional expressions of faith, solidarity, patriotism, loyalty, or
piety are all well and good but they do not constitute rational
arguments.

Also, understand that macro code is code that you write. You control
every detail of the code...

Please understand that in the real world of software development, the
lone programmer doing an entire job by himself is no longer at all
commonplace.

That way, you'll be able to discuss this issue and have us respect you
as somebody who tries to fix their knowledge gaps, rather than pity
you as a casualty of groupthink.

Hey! I've been prospecting on Usenet and I think I've just struck a
rich vein of irony! This one guy, see, he makes all these expressions
of his faith, ignoring reason, and then he accuses his opponent of
being a "casualty of groupthink"!

 

[Series Expansion]

Unless you're writing wizard macro-defining macros[1], debugging macro
code is fairly straightforward

OH RLY?

RLY. I've done it, and I'm assuming Spiros has too.

It's strange to be told, repeatedly, that things I do routinely,
without a great deal of difficulty or aggravation, are in fact
ridiculously hard and painful.

Real debugging or some sort of cargo-cult debugging, going through the
motions and having faith that it will have the intended effect?

(During the war years, aboriginals who saw cargo planes landing and
taking off at temporary military airfields sometimes created their own
runway-like features and cardboard planes, hoping this would attract
real planes with valuable goods to sometimes land there. Of course,
this was a lot less effort than developing their technology and
economy and operating a real airport!)

 

[Series Expansion]

I meant to say "Spiros", not "Spirol".

And I'm sorry about the derogatory tone of my message. However, please
understand, Mr Expansion (?), that it's quite exhasperating trying to
offer new information to somebody who...

What new information? You're mostly repeating yourself now, and yet
you're surprised when I do likewise?

 

[Series Expansion]

I'd really kill my parents if they gave me such a name...

[snip]

I just explained why the package system won't.

No, you didn't.

Yes, I did.

No, not in CLOS. You better read up on CLOS before you post such crap.

How rude.

[snip]

No.

No.

No.

No need to. Just doesn't happen!

Denial is a wonderful thing.

What was the next stage again? Oh, crap, it was anger, wasn't it?

Yep, I do too in Java. No so in Common Lisp. There's freedom and
liberty.

The mantra of a man of faith and deep patriotism. Not, however, a
reasoned argument of any kind.

Ah, I love the smell of efficiency in coding in Lisp all day long ...

It takes that long?

 

[Pascal J. Bourguignon]

I've looked for instructions before, but had no luck. I miss the days
when I could do gcc compiles from emacs and debug via its gdb
interface. I gather from what you're telling me that the emacs gurus
have sussed out how to tie emacs into the JVM, a remarkable
achievement indeed. This is great; I can start using emacs for my
Java development once I get this information.

http://jdee.sourceforge.net/

 

[gugamilare]

No, YOU read the ASCII string and do syntactic analysis on it. I
prefer to have tools that will do that sort of crap for me.

That is what he meant - Emacs does this, not we.

To you guys, Lisp is like some magic elixir that grants lifelike
behavior and extraordinary properties to anything infused with it,
isn't it?

You tell me that ain't also the case of Eclipse? I am sure you think
that Eclipse is a very flexible and can do very extraordinary things
with you programming environment. And we are not saying otherwise.

Well, I've got news for you. Here in the real world, there ain't no
silver bullet. No philosopher's stone. No magic spell a wizard can
cast to make brooms come to life and carry water or whatever. Instead,
we have this thing called "engineering". We actually have to figure
something out and then build it to run on ordinary electricity or
gasoline. And if something is impossible, it just plain won't work.

What are you assuming impossible here? Lisp can do great things. No
one ever mentioned anything about impossible things or doing some kind
of magic, and, when we do, we are referring to the features that the
language have, not magic itself.

Apparently, gugamilare disagrees.

I DON'T! Read my last posts and NEVER put words in my mouth again.

Prompts are so 1985. And wouldn't you need an MDI window system to
have anywhere else for it to expand into BESIDES your source file?

You say that Java does not have a prompt where you can test and debug
things? Are you saying that Linux terminals are useless? make /
Autoconf is made on top of them. Don't you compile code and download
packages from the shell at all?

Yeah, yeah, that's what they all say.


Fan-bloody-tastic. You know that can't possibly work reliably, right?

You are such a child, you have no idea of what you are saying.

It's one thing if the dependency analysis is done by automation when
it's an external tool like automake. It's another if it's done by part
of the same code base undergoing the dependency analysis. Now, the
dependency analysis itself might affect the dependencies, which is
precisely the kind of headache I was alluding to earlier with self-
referentiality.

Lisp way of handling things is not different from that. It is a
automake-like feature, the only difference is that it is written in
Lisp (and in separated files, just like the makefiles and stuff).

SLIME must be magic, then, if it can grant the editor the knowledge
that SuperVGA has been invented from *inside its internal script
interpreter* without even a droplet of native C code to actually talk
to the display hardware. It's amazing! It's fantastic! It makes
Windows Plug'n'Pray obsolete! It's ... slime!

Slime connects to the lisp environment and asks questions about where
the definition files are. It just works, you really should stop making
so dumb arguments and learn Lisp before anything else.

Well, it's that or someone was wrong about SLIME being written
entirely in an editor's scripting language, or you're wrong about what
it can do, or (least plausible of all) someone's definition of
"powerful IDE" allows the possibility of one being a prompt-driven
terminal-mode archaism from the 80s.

He is not wrong. This is just every-day use of Slime. I use this
feature every day I program in Lisp. You tell me that Eclipse for
instance can't find the source definition of something if you ask it
to do so? If the answer is no, then I can only say that Eclipse sucks,
this is not possible.

Please read up on etiquette, polite society, civilization, and Emily
Post before you continue posting personal attacks!

He is serious about that, he is not attacking you or stuff like that.
You do sound like a novel writer talking about quantum mechanics. You
need to learn things before you can attack them, or you just don't
attack them. You won't see me in comp.lang.java unless I learn Java.
And I certainly won't troll over there like you are trolling over
here, if anything I will complain of some little things I don't like
about Java.

 

[Pillsy]

Real debugging or some sort of cargo-cult debugging, going through the
motions and having faith that it will have the intended effect?

Real debugging. Lisp macros are a good deal less arcane than you seem
to think; the ones you write 95% of the time are really just
straightforward Lisp functions that act on a tree made up of conses.

Cheers,
Pillsy
[...]

 

[gugamilare]

While you lot apparently just use them in a gung-ho manner until the
sky falls down on you.


I'm sure Ted Bundy's mother was proud of him, even for a while after
everyone else started telling her he was a bad seed.


The problem is that "the code which uses them" includes any code that
contains the text that triggers the macro and that occurs after the
macro in evaluation by the compiler.



That's still compiling, and it can be made silent easily enough:

#define malloc(x) ((void *)1)



It's type safe compared to Lisp! Though Java is "type safer" than it
is since its casts are tightly regulated, and mis-casts produce a
clean run-time error.


Still not getting it, I see. To change the definition of malloc() one
would edit the source file containing malloc(). Whereas that macro
could be stuck pretty much anywhere and blow things up. Locality of
side effects of code changes is destroyed by macros.

Lisp is not different than this. If you define a function, and then a
macro with the same name, it will complain (emit a warning) which an
average Lisp programmer (even beginners) will note and correct it.
Macros are not very different from functions. Whatever problems you
cause with macros, you cause with functions. And, whatever safety
functions provide, functions also provide. You fail to see this
because you NEED DESPERATELY to learn Lisp so you can understand this.

The problem with macros that I've been getting it is their inherent
ability to alter the behavior of far-away code from pretty much
anywhere. A function has to be intentionally invoked by some code to
have effect there; a macro has to be coded to operate ON some other
code to have effect there. It's easy to whip up a C macro that affects
all the code that uses strlen() or all the code that uses char *
pointers or turn all the code's floats into doubles. Some of these
uses might be useful. All of them are potential maintenance headaches,
since

This is not the same case as CL. We are not dumbs.

1. Someone reading the affected code might assume it does what it
   says at face value, and the macro changed that;
2. Even if they know, or suspect, otherwise, finding all the macros
   that potentially alter the behavior of a particular bit of code
   is an exercise in haystack-needle-finding.

Believe me when I say, this is not the case with Lisp at all. Things
work differently.

Lisp macros apparently are slightly more limited, having to take the
form of function calls rather than arbitrary code fragments.

Sorry, but, I don't follow. What is the difference? Arbitrary forms
are arbitrary code fragments. I really don't get it.

Typos are non-thoughtful more or less by definition.

Typos are the programmer's problem, not language's one, just like
infinite loops.

I've written lots of macros, though, in a variety of places and
contexts.

But not CL macros. They are VERY different. You won't understand that
until you can actually write CL macros.

 

[Pascal J. Bourguignon]

Prompts are so 1985.

Notice that in 1985, GUI existed and were commercialized already for a
few years.

However, your comment seem to show that you think that GUI are better
than CLI.

I agree that GUI are generaly nice. Unfortunately they're also less
productive than CLI.

The main point here is that the theory behind GUI is that it's the
user who is working, the GUI presents to the user objects that he can
manipulate with the mouse and menus.

On the contrary, CLI are means to give orders to the computer, to let
the computer do the work.

Emacs, even when working in a GUI, shows almost only characters in its
windows, because first it's not a picture editor but a text editor,
and the point is not to let the user manipulate himself the texts, but
as much as possible to direct emacs to do the editing instead of the
user. That's why there's this mini-buffer where the user is
constantly giving commands to emacs, and that's why emacs includes a
lisp system so the user can program text modification procedures
instead of repeatitively doing them himself.

Almost all Lisp implementations contain also such a CLI, Command Line
Interface (called REPL in Lisp since it's implemented by calling the
operators READ, EVAL, PRINT and LOOP). So instead of clicking on
buttons on menues, we can give commands, and add and improve the
commands we may give to your lisp systems. This way, instead of doing
the work yourself, you can just give commands to the computer and it
will work for you.

 

[gugamilare]

Series Expansion <[email protected]> writes:

I'd really kill my parents if they gave me such a name...

[snip]

I just explained why the package system won't.

No, you didn't.

Yes, I did.

No, not in CLOS. You better read up on CLOS before you post such crap.

How rude.

[snip]

No.

No.

No.

No need to. Just doesn't happen!

Denial is a wonderful thing.

You are being hypocrite. You have just ignored everything he explained
about the package system and how methods are defined, and complains
about him denying something you said. Please not that everything he
said "no" to are things that are no longer valid IF you understand his
argument - which seems almost impossible.

What was the next stage again? Oh, crap, it was anger, wasn't it?

Yes. For now he is just denying that you don't have idea of what you
are talking about, and that actually you can understand what he is
trying to explain. It will take a while until he realizes that
convincing you is just hopeless because you ignore or misinterpret
every damn good point we make.

It takes that long?

Wow, I am impressed. You are so convincing with all these arguments.

You know what? I will not waste one more precious minute of my time
trying to explain everything to you. If you want to continue this
debate, read the ENTIRE book which is here: http://www.gigamonkeys.com/book
, following everything like the newbie _in Lisp_ that you are. Than we
can continue this conversation.

 

[Pascal J. Bourguignon]

The problem is that "the code which uses them" includes any code that
contains the text that triggers the macro and that occurs after the
macro in evaluation by the compiler.

This is false.

Haven't you read the tutorials on lisp macros at the URIs I gave?

That's still compiling, and it can be made silent easily enough:

#define malloc(x) ((void *)1)

And this is something that you may try to do in Lisp, but which will
pose absoltely no problem because it has a very well defined and sane
semantic:

(defun malloc (size) (make-array size :element-type '(unsigned-byte 8) :initial-element 0))
(defvar malloc 1)

(list malloc (malloc 20))
--> (1 #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0))


Why do you insist talking about things you don't know?

It's type safe compared to Lisp!

No it is not.


-*- mode: compilation; default-directory: "/tmp/" -*-
Compilation started at Sat May 16 22:53:56

SRC="/tmp/a.c" ; EXE="a" ; gcc -I. -L. -g3 -ggdb3 -o ${EXE} ${SRC} && ( cat ${SRC}; ./${EXE}) && echo status = $?

#include <stdio.h>
int main(){
printf("\"one\"+2=%d\n","one"+2);
return(0);
}

"one"+2=8175
status = 0

Compilation finished at Sat May 16 22:53:56




C/USER[31]> (+ "one" 2)

*** - +: "one" is not a number

The problem with macros that I've been getting it is their inherent
ability to alter the behavior of far-away code from pretty much
anywhere. A function has to be intentionally invoked by some code to
have effect there; a macro has to be coded to operate ON some other
code to have effect there.

We are discussing Lisp macros and this is false.

Of course a macro can be programmed to expand to code that modify the
global state, for example, it could define a new global variable, or
it could define (or redefine) a function or a macro.

But if you don't want your macro to define a function, then you don't
program it to do so, and it won't have that global effect.

Then the effects of a macro invocation will be strictly localized.


Notice that defining global variables or (re)definining functions or
macros can also be done by functions in Lisp.

It's easy to whip up a C macro that affects

Forget all you know about C macros, we're not discussing cpp, we're
talked about Lisp macros.

 

[Pascal J. Bourguignon]

I'd really kill my parents if they gave me such a name...

[snip]

I just explained why the package system won't.

No, you didn't.

Yes, I did.

No, not in CLOS. You better read up on CLOS before you post such crap.

How rude.

[snip]

No.

No.

No.

No need to. Just doesn't happen!

Denial is a wonderful thing.

This is not denial. It's damage control. We wouldn't want to let
innocent nearby readers believe your lies.