Ironically, a year or so ago, in a crossposting language flamefest,
Python users were scared to death by macros, and warned against their
dangers.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso wrote:
> Ironically, a year or so ago, in a crossposting language flamefest,
> Python users were scared to death by macros, and warned against their
> dangers.
But that was when Python didn't have them.
mikel <·····@evins.net> writes:
> Paolo Amoroso wrote:
>> Ironically, a year or so ago, in a crossposting language flamefest,
>> Python users were scared to death by macros, and warned against their
>> dangers.
>
> But that was when Python didn't have them.
"Programming languages teach you not to want what they cannot
provide."
-- Paul Graham
(This doesn't exclude Common Lisp, of course.)
Zach
Zach wrote:
> "Programming languages teach you not to want what they cannot
> provide."
> -- Paul Graham
>
> (This doesn't exclude Common Lisp, of course.)
I guess this explains why Lisp programmers want everything. :-)
--
Fred Gilham ······@csl.sri.com || GOVERNMENT: A large charity
organization with a coercive fund-raising arm. PUBLIC SCHOOLS:
Government-run (see above) schools with coercive admissions
departments.
Fred Gilham <······@snapdragon.csl.sri.com> wrote:
> Zach wrote:
>> "Programming languages teach you not to want what they cannot
>> provide."
>> -- Paul Graham
>>
>> (This doesn't exclude Common Lisp, of course.)
>
> I guess this explains why Lisp programmers want everything. :-)
Except a standard sockets library? :)
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
Every program has at least one bug and can be shortened by at least one line.
By induction, every program can be reduced to one line which does not work.
> Except a standard sockets library? :)
Who needs a standard one when everyone already has one? I mean, is
there a reasonable common lisp implementation without a sockets
library?
The problem is that Lisp programmers want everything, and the language
doesn't discourage them from wanting it, so they tend to program it
without waiting for a standard! Yes, that's my story, and I'm
sticking to it! :-)
--
Fred Gilham ······@csl.sri.com
Behold, how good and pleasant it is when brothers dwell in unity. It
is like the precious oil upon the head, running down upon the beard,
upon the beard of Aaron, running down on the collar of his robes. It
is like the dew of Hermon, which falls on the mountains of Zion. For
there the LORD has commanded the blessing, life for evermore. -Ps 133
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> > Except a standard sockets library? :)
>
> Who needs a standard one when everyone already has one? I mean, is
> there a reasonable common lisp implementation without a sockets
> library?
Yes, but are any of them the same?
> The problem is that Lisp programmers want everything, and the language
> doesn't discourage them from wanting it, so they tend to program it
> without waiting for a standard! Yes, that's my story, and I'm
> sticking to it! :-)
Like FFI. Now here is an area that could really use the same
interface across implementations. Not sure how that can be done with
all those different ABIs though.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
On Thu, 2 Dec 2004 01:54:56 +0000 (UTC), Karl A. Krueger
<········@example.edu> wrote:
> Fred Gilham <······@snapdragon.csl.sri.com> wrote:
>> Zach wrote:
>>> "Programming languages teach you not to want what they cannot
>>> provide."
>>> -- Paul Graham
>>>
>>> (This doesn't exclude Common Lisp, of course.)
>>
>> I guess this explains why Lisp programmers want everything. :-)
>
> Except a standard sockets library? :)
>
John shouts! SOCS?? socks are in the droar..
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
mikel wrote:
> Paolo Amoroso wrote:
>
>> Ironically, a year or so ago, in a crossposting language flamefest,
>> Python users were scared to death by macros, and warned against their
>> dangers.
>
> But that was when Python didn't have them.
Hey, calm down. They still don't have them. They just have version 0.3
alpha. Let's wait until they have to deal with the real problems... ;)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
No it doesn't! Python doesn't get macros! You guys are going to get me
in trouble with the Python crowd [grin].
OK a couple of people made this point already, but then we had, for
example:
>> [in an old thread] Python users were scared to death by macros, and
>> warned against their dangers.
>
> But that was when Python didn't have them.
So I just wanted to emphasise that Logix is not Python. Logix compiles
to Python byte-code, exposes much of the underlying Python semantics,
and supports a very Python-like syntax. So it can feel almost exactly
like Python with macros. BUT the project is in no way connected with
Python development, and is in no way an attempt to push Python in a
certain direction. The Python community haven't in fact been involved
in any way - the web site only just went up and before that it was
just me.
I'm also posting because I hope I can learn something from you folks.
I can easily make incompatible changes at this stage, so I'd like to
try and figure out if I've missed anything important.
E.g.
> Paul Graham in Arc was considering allowing something like
> [introducing new variables without requiring a nested block] but
> found that it caused problems with allowing elegant macros in the
> language
I would love to learn more about this, as Logix does allow this. My
hunch is that this will be something along the lines of "macro foo
looks icky" rather than "macro foo is twice as complex".
> How does the macro author parse the python source input? Are
> there any small examples you can post?
Try http://logix.livelogix.com/intro.html
As in Lisp, all parsing of both quoted and un-quoted source is done
before macro expansion kicks in. The only difference is that the
mapping from source to code-data (Logix equivalent of s-exprs) is more
complex.
> Where were they when Norvig explained that Python does not need
> macros!
I'm well aware of the position of the Python community on macros. I
think they're absolutely correct given their goals. The goals of Logix
are different.
Doesn't *need* macros? That's a valid opinion. A claim that Python +
macros is no more expressive than just Python would be false.
> Remember when the guiding principle of Python was simplicity?
It still is. Logix is not Python. Mind you, on a separate note there
are some grumblings in the Python community about loosing site of this
principle. Function decorators (just added in Python 2.4) are
particularly controversial.
>> [if the syntax is not very simple] creating or manipulating a
>> syntax tree is so complicated people avoid it.
>
> That might be the point: to scare people away from using it.
No, that was never the intention. Implementing macros in Logix can be
more complex than in Lisp - that's inevitable with a more complex
syntax. My goal has been to keep this extra complexity to the barest
minimum. I think it's turned out pretty well. Time will tell.
> Hey, calm down. They still don't have [macros]. They just have
> version 0.3 alpha. Let's wait until they have to deal with the real
> problems... ;)
I would be really grateful if you folks could offer the benefit of
your experience here. Can you see limitations in the Logix macro
system with respect to Lisp? What are the "real problems"? If language
designers are to avoid re-solving the same old problems, it will be
because those who know better are around to advise. I'm all ears!
Thanks
Tom.
···@livelogix.com (Tom Locke) writes:
> I would be really grateful if you folks could offer the benefit of
> your experience here. Can you see limitations in the Logix macro
> system with respect to Lisp? What are the "real problems"? If
> language designers are to avoid re-solving the same old problems, it
> will be because those who know better are around to advise. I'm all
> ears!
How does the Logix macro system compare to Dylan's? (If you're not
familiar with Dylan, it might be worth your time to look it up--it was
a Lisp dialect/spinoff/whatever that dropped the parenthesized syntax
in favor of a more ALGOLish form. Then they had to do something
clever/gross to put macros back in. I'd be interested to know how what
they did compares to what you've done.)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
> How does the Logix macro system compare to Dylan's?
Dylan has a non-procedural template based macro system (i.e. you don't
get to use arbitrary code to build the macro-expansion). It has some
facility to invent new syntax, but more limited than in Logix, e.g.
you can't create a new infix operator.
I'm not a Dylan expert, but from what I've seen, you can push the
template system surprisingly far, although it quickly gets painful.
Logix's macro system is really just the same as Lisp's (unless someone
on here can demonstrate otherwise!), so very different to Dylan's.
There was a system invented to add full procedural macros to Dylan,
though I confess I haven't read up on it. I don't believe it has been
implemented. I also know they had plans to push the syntax extension
further - again, just plans.
Tom.
Tom Locke wrote:
>>Hey, calm down. They still don't have [macros]. They just have
>>version 0.3 alpha. Let's wait until they have to deal with the real
>>problems... ;)
>
> I would be really grateful if you folks could offer the benefit of
> your experience here. Can you see limitations in the Logix macro
> system with respect to Lisp? What are the "real problems"? If language
> designers are to avoid re-solving the same old problems, it will be
> because those who know better are around to advise. I'm all ears!
Good response! Check out Jonathan Bachrach's work on D-Expressions and
the Java Syntactic Extender. It contains a lot of discussion that should
be relevant to your work. See
http://www.ai.mit.edu/~jrb/Projects/dexprs.htm and
http://www.ai.mit.edu/~jrb/jse/index.htm
Pascal
--
The big bang way only works for god, everybody else has to use
evolution. - David Moon
> Check out Jonathan Bachrach's work on D-Expressions and
> the Java Syntactic Extender...
Thanks for the links. I was already aware of this work, although I
confess I had not read the paper carefully (have now). I was not aware
that they had applied the ideas to Java, although the only step
forward here seems to be that they were able to take advantage of
Java's dynamic linking stuff in order to streamline the 'compiler
plugins' idea from the Dylan work. (with Python's very-late-binding
things gets easier still)
I believe the Logix macro system measures up to the standard of
"Lisp-style macro power and simplicity" as set up by the D-Expressions
paper. From this work I cannot see any "real problems" that have not
been addressed. The main superiority of the Dylan work compared to
Logix is in performance and static analysis (e.g. type checking). Once
you accept the down-sides of run-time binding, a lot of problems get a
lot simpler. A smaller advantage they have is that (unlike in Logix) a
recursive macro can be written without a forward declaration.
The degree to which syntax can be extended with their 'skeleton syntax
tree' approach is however severely restricted in comparison with
Logix. (That's why I hadn't studied the work more carefully before
now). To use the phrase from the paper, the Dylan macro system can
introduce "new kinds of bracket". With Logix one can also create
infix, postfix, and 'mixfix' (e.g. ?: from C) operators. It is also
possible to do some nice tricks with unparsed text - e.g. define your
own string quoting operator, or define XML (Logix will be able to
capture XML syntax precisely - once a small enhancement is released).
Another significant advantage Logix has, is the ability to freely mix
languages. A program source could include, for example, literal XML
data, SQL queries and shell-like file manipulation commands, without
having to quote any of it in strings, and all sharing the same
run-time variable bindings.
The Logix approach is neither a traditional AST approach, or a
Lisp-like skeleton-syntax-tree approach. Instead, a program in Logix
is simply an expression, made up of operators and operands where *each
operator has it's own mini-grammar*. This gives us something that is
very close to a fully extensible grammar, but that can be extended
very simply indeed. Much more simply IMO than approaches where a
global grammer can be manipulated. For example, in the work that you
(Pascal) pointed me at a while back:
http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg04682.html
Tom.
p.s. Assuming there is further interest in this thread, is this still
the appropriate forum? If yes, perhaps the subject-line could be
switched to something less flame-bait-ish to the Python crowd? ;)
In article <····························@posting.google.com>,
···@livelogix.com (Tom Locke) wrote:
> Another significant advantage Logix has, is the ability to freely mix
> languages. A program source could include, for example, literal XML
> data, SQL queries and...
Nonsense. One no longer needs to mix. Lisp has won, and with it sexpr
syntax.
> p.s. Assuming there is further interest in this thread, is this still
> the appropriate forum? If yes, perhaps the subject-line could be
> switched to something less flame-bait-ish to the Python crowd? ;)
"Python gets macros" is an inflammatory way of talking about Python
getting macros?
Besides, as Gabriel said, "Pick a fight."
kenny
Tom Locke wrote:
> I believe the Logix macro system measures up to the standard of
> "Lisp-style macro power and simplicity" as set up by the D-Expressions
> paper. From this work I cannot see any "real problems" that have not
> been addressed.
Here is a question, without knowing yet whether this entails an actual
problem or not: How do you ensure that gensyms are indeed unique? Do you
have some concept of uninterned symbols, or do you just use
automatically generated names?
Pascal
--
The big bang way only works for god, everybody else has to use
evolution. - David Moon
>How do you ensure that gensyms are indeed unique? Do you
>have some concept of uninterned symbols, or do you just use
>automatically generated names?
The Python VM resolves globals (i.e. module variables - Python has no
program-level globals) at run-time based on string equality, so
ultimately we have to do name generation.
The current approach is to simply include a counter in the generated
name, and inc the counter with each gensym created. This is only safe
if a usage pattern is followed - a macro must newly create any gensym
included in its output. For example, a macro generating macro, where
the generated macro required gensyms, would have to include the
creation of these gensyms in the generated macro, rather than creating
gensyms in the generating macro.
I belive with this usage rule, the simple counter based approach is
sufficient (bearing in mind that names need only be distinct within a
module). However a more robust approach is also possible. By assigning
names to gensyms during byte-code generation rather than during macro
expansion, gensyms could be given names based on object identity.
Because the byte code generator has the code-data (=AST) of the whole
module, these names could be guaranteed unique.
The byte code generator could easily accommodate this approach. This is
something that needs doing.
Tom.
[For those who haven't followed the thread, Logix is described at:
http://logix.livelogix.com]
Tom Locke wrote:
> So I just wanted to emphasise that Logix is not Python. Logix compiles
> to Python byte-code, exposes much of the underlying Python semantics,
> and supports a very Python-like syntax. So it can feel almost exactly
> like Python with macros. BUT the project is in no way connected with
> Python development, and is in no way an attempt to push Python in a
> certain direction. The Python community haven't in fact been involved
> in any way - the web site only just went up and before that it was
> just me.
I saw on your "future work" page you might be considering another VM in
the future such as C#/Mono or Parrot.
I could almost see implementing some of Logix's macro functionality in
boo, a python-like language for .NET/Mono: http://boo.codehaus.org/
It already has facilities for custom macros, attributes (like decorators
in python), and compiler pipelines, but the macros aren't as powerful or
simple to write as in Logix. See also
http://jira.codehaus.org/browse/BOO-95
I was wondering what you thought about it. It would be great to have
more powerful macro functionality like you have implemented. Boo is
statically typed with type inference, so macros couldn't work as
dynamically Logix, but the resulting code would be as fast as C# or Java.
boo uses the ANTLR parser/lexer. I'm not sure how to add hooks for new
custom syntax rules on the fly, especially adding custom operators like
>> or ++. We'd have to do that or else replace ANTLR with a custom parser.
Doug Holton wrote:
> I saw on your "future work" page you might be considering another VM
in
> the future such as C#/Mono or Parrot.
>
> I could almost see implementing some of Logix's macro functionality
in
> boo...[snip]...I was wondering what you thought about it.
> It would be great to have more powerful macro functionality
> like you have implemented.
These are two different things. Mono, or perhaps I should say the CLI,
and Parrot are VMs, Boo is a language.
Logix is a language (or rather a meta-language) that runs in a VM
environment. Currently that VM is the Python VM. By targeting a
particular VM, we will typically share a lot of semantics with other
languages on the same VM (in our case it's just Python). E.g. Logix has
Python's data-types, object model, module system, exception
mechanism... We could swim upstream and create our own semantics for
these, but that would cost us in terms of efficiency and iterop.
But when you talk about Logix and Boo, it's not clear what this means.
Create a hybrid with some features from each? That sounds like a whole
new project.
A language with Lisp-like extensibility and static typing is not
(AFAIK) something we know how to do right now. In particular, compile
time type errors will be in terms of the code after macro expansion,
and could be meaningless to the user.
One thing that is of interest, is how we might allow some stuff to
(optionally) be declared statically in order to improve execution
speed. e.g. in Lisp, certain types can be declared statically, thereby
eliminating run-time checks. Also, in CLOS, more stuff is fixed
statically than in Python's object model - again less to do at
run-time. The Python VM doesn't have scope for either of these
enhancements, whereas both Parrot and the CLI do.
Tom.