Am 30.11.2014 um 20:18 schrieb Richard Fateman:
I just don't understand this emphasis on the difficulty of macros.
Issue is that tools don't know about these preprocessors.
This affects IDEs when finding the definition of a name, or when
refactoring; also stack traces tend to not reflect what's in the file.
I have no problems with macros actually, it's just that going outside of
typical language usage means you lose a lot of infrastructure and tool
support.
Some people are happy to run their source code through a macro processor
like M6, just for the fun of it. But I don't think that is at all
necessary.
Well, for fun experiments rarely go beyond three digits in LoC, so these
people never hit the actual problems.
Partial evaluation isn't doable at all.
I don't know what you mean by partial evaluation.
Difference between lazy and eager evaluation.
> Is this something you
think that Lisp does? Maybe confused about quote?
Quote is Lisp's way of deferring evaluation, yes.
Well, sort of, unevaluated expressions are also lists.
Let me put up an analogy: What I fear is that the Lisp patterns
presented are a shiny, working, elegant racing car. However, when doing
it in Python, the best design might be an SUV because the track is a bit
rougher, and we'd end up with something with a really good engine but it
would be difficult to put that power to actual use.
That's not really what Norvig does. Quite the contrary. His programs are
a minimal framework to exhibit the performance that he wants to demonstrate,
for the most part.
I'll leave that to the people who actually try his recipes out.
Also, you need to be 150% clear about the semantics of quote. I found it
extremely hard to deal with that - the theory was easy enough, yet in
practice I found myself tripping over it at every other opportunity, and
it didn't get better with practice.
I find this surprising.
I can imagine.
> You can read (in Norvig's book) a program that is
the Lisp evaluator (actually, Scheme).
Ah, that reminds me of my first real schooltime programming project.
Which happened to be a minimal Lisp interpreter :-)
> It shows what quote means.
As I said, I know fully well what quote means.
It's just that practical use somehow didn't work out. I kept quoting
stuff that shouldn't be quoted, and vice versa. Maybe I was too young
and didn't think clearly enough about them, maybe I have some thinking
defect that makes them hard on me, maybe I have a tendency to approaches
that simply do not work well for Lisp. Maybe the manuals I was using
simply didn't make clear enough which functions would unquote which
argument.
Frankly, I don't know - but I found it extremely refreshing that
Haskell, being all lazy evaluation, does not have this distinction :-)
Oh, Haskell does not need macros either. I think that's because lazy
evaluation means there is no difference between quoted and nonquoted,
but I can't be 100% sure about that.
If I recall correctly, Scheme originally did not have macros. Maybe
still doesn't, just as an "extension".
I'd be quite surprised if it didn't.
But then I haven't been following Scheme or CL in the past decade. Not
too closely anyway, I guess things have developed a bit in that time.
2. If they are not, it is probably a crappy unnecessary use of macros,
written by a naive programmer.
:-)
3. Look at Norvig's book and see how often he uses macros. Rarely.
And see how long they are. (2 lines?)
I'm unconcerned about Peter's use of macros.
What I'm concerned about is the code that they replace, and how good
that code could be abstracted out on the Python side.
Each time a piece of macro code is used in a Lisp program one can
replace it with a piece of regular code. In fact that is exactly what macro
expansion does.
Ah, but the point is that it is *not* the same, as then there would be
not reason to use a macro in the first place, right?
> Presumably Python programmers could do the same by hand.
Unless the code becomes too clunky that way.
Which is what I suspect will happen - unless Peter's macro usage is
really that superficial that it doesn't matter.
I guess that's something to check when applying that book's lessons to
Python.
What kind of
design we'd need, whether it would fit with the rest of the design. What
I fear most is a downhill creep in quality - each time you build a
workaround for a macro you can't do in Python, you lose just a small
amount of design quality, but if you have a dozen macros, the overall
design could have become so bad it's unusable.
Again, you assume that a lisp program is a tangle of macros.
No, I'm assuming that Peter's code is at least a dozen macros.
And I fear that inlining all these macros might make the design too
clunky to work with - though as I said, if his macro usage is slight
then it might be a non-issue.
I do know it's very easy to overlook how much a macro changes. I have
done some experimenting with manual inlining of functions, and a
combination of innocuously-looking functions could become a tangled
mess, very quickly.
I'll leave that issue to real experimenting though, I do not think we
can find out more by arguing on a what-if basis.
Fortunately, the unskilled people who do not become skilled tend to go
away in a volunteer project.
It's still something to look out for. Some of our codebase has become
unmaintainable already (I'm looking at you, runtests.py - though that
specific file does not suffer from design problems but from too many
feature additions and too little refactoring).
I don't know about sympy code base, but I think the general belief in
my (computer science) department is that programs written by students
must be reworked by others before it is ready for prime-time (95%).
distribution outside our department.
The code base could certainly use some work, but I have seen worse
written by supposedly-senior programmers.
We can certainly benefit from algorithms.
Less so from "doing things the Lisp way" if we're working in Python.
The problem is that separating algorithms from "the Lisp way" isn't
always easy. And an important part of writing a framework in programming
language X is "doing it the X way" (says he who has participated in such
projects for multiple values of X).
I think that writing programs in Lisp does not define 'a way' because there
are generally many ways of accomplishing the same task using different
"paradigms" ... e.g. functional, imperative, ... whereas it seems to me
that Python is supposed to have one way to do each thing. (true?).
This is in fact Python philosophy, but it applies just to language
features, not API design.
Actually I'd be very surprised if any language design could enforce a
"one way to do each thing" paradigm at the API level, programmer jokes
like Intercal aside.
So maybe a lisp program that is heavily "functional programming" style
is hard to do in Python ? But you insist that Python supports this,
so I don't know.
Python is functional all right, in the litmus test sense "can it
construct new functions at runtime".
However, to make the functional aspect clean and matter-of-fact, closure
construction needs to be easy and free of clunkiness, and Python
requires an extra "lambda" keyword, naming all parameters (instead of
just leaving them unbound variables), and an extra colon; it's not too
bad but I suspect nobody is going to build a monad transformer library
in Python, simply because that pattern would become so clunky that it's
useless. (A bit like the situation of template-based functional
programming in C++: Yes it can be done, but it's too ugly to live.)
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/547B7E45.4060804%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
