Re: macro for shorter array syntax

Jon Harrop <jon@xxxxxxxxxxxxxxxxx> writes:

That doesn't seem outrageously difficult to me. What is the equivalent Lisp?

IMO, this example isn't particularly productive. My point is
succinctly summed up by the phrase "apples and oranges". But I'll
elaborate anyway.

For example, is your question asked with or without extending Lisp to
hypothesize the existence of an infix parser?

How is OCaml on adding readmacros, which Lisp can do easily. I bet if
OCaml had a readmacro facility, the act of writing an individual
readmacro would be simple. But adding a readmacro facility is a
non-trivial injection into a parsed syntax. So it's not going to be
pretty. I would not ask that of a parsed language. I would simply
observe that parsed languages have certain useful advantages and so do
Lispy languages; I prefer the latter, which is why I use Lisp for lots
of things. If you don't, then perhaps you are better placed with
another language or perhaps you should extend Lisp to accommodate
parsed syntax, which can be done. And having done this several times
myself, I can tell you that extensions such as you describe are just as
easy to write once you hypothesize the existence of a parser at all.
Hence the remark about "apples and oranges".

I'm not familiar with the grammar of OCaml, though it looks very like
ML, and in fact I'm not sure its details matter--I'm pretty confident
that the Lisp reader can be modified to have OCaml syntax, to include
the ability to write syntax extensions in similar form to what you've
just written.

Are you confident you can modify the OCaml reader to accept Lisp
syntax? If not, then what is the relevance of the fact that each can
do something the other can't in some uninteresting syntactic way.
We're confident that using macros is useful to us, and we're happy
using macros. No one is trying to tell you not to use OCaml and not
to avoid macros. But I think the observation someone (perhaps more
than one person) made about the fact that languages where macros are
painful or restricted or non-existent will attract different
personalities than languages where macros are easy and general is spot
on. Until you have accounted for differences in preference between
people who use languages, stats on how people use certain languages in
isolation are not useful science.

In deciding whether people would prefer Lisp or Scheme, I often pose
questions about how they like to express themselves, including
questions about whether they prefer functional abstraction or macro
abstraction, in order to place them in a community that will be most
happy for them. I don't think Scheme people would be happy with CL,
nor vice versa, but I don't consider that fact an a priori criticism
of either language.

I think there is room for some interesting dialog between language
communities, but I think taking potshots randomly is not the way to do
that.

Good experimental data is something one takes the trouble to create
control groups for. Good abstract arguments are things where one
takes the trouble to list their dependent assumptions and to abstract
away from incidentals.

Gabriel and I had enormous difficulty in writing our paper on
namespaces because it kept looking like a comparison of Lisp and
Scheme rather than of single namespace vs dual namespace. Even now,
people still tend to read it that way, and like many debates, they
support their home team and have to read carefully to see that the
debate has legitimate points on both sides. But my introduction of
the terms Lisp1 and Lisp2 to substitute for CL and Scheme at least got
us to the point where the debate was close to balanced, since it was
possible for people to imagine a Scheme with 2 namespaces (ISLISP is
sort of close to that in certain ways) and or a CL with one namespace
(Dylan is sort of close to that in certain ways). But my point isn't
to open those debates--just to say that having a serious debate is
hard work on the part of the debate partners, being fair to one
another. Since it's you who seems to want to debate everything about
the language, you could start by doing your homework better before
being critical... and when being critical, you could help by being
articulate and not making people have to infer what you are
criticizing and on what basis.

We aren't going out of our forum to push Lisp on you--you're coming
into our forum to learn about the language, so the burden is not on us
to convince you to stay. A language forum does not exist so that people
can justify their existence to others; it exists so that people who want
to come there voluntarily can meet with a friendly community who are
supportive and helpful. That doesn't mean we can't stand critical
discussion, but it does mean that there should be a point--a way we are
asked to change or grow--and one that is realistic and accommodates the
needs of the community. I don't see any such constructive suggestion
underlying this post, nor many others I've read from you.

If you don't like the language, by all means, avail yourself of the
brightly lit red EXIT light... but if you wish to stay, please engage
the language in the same productive and upbeat fashion requested of
others. Learn the language on its own terms. It is not other
languages. (There are other languages for the purpose of being other
languages. Lisp exists for the purpose of being itself.)

Extending the pattern matcher with this, and support for expression
sequences represented as balanced binary trees was easy enough.

Now look at the way Lispers use macros:
Array syntax:[...]
Pattern matcher:[...]
Optimization:[...]
Currying:[...]
The same topics come up here over and over, and each time everyone posts a
new macro to implement an old syntax.

You do a lot of your "debating" by merely citing odd observations and
then jumping to bizarre, unsupported conclusions. I've got to say,
I'm close to the end of my tolerance for this because I don't feel the
language has anything to answer for, and I think a lot of what you're
doing is not resulting in you being any happier nor anyone else being
enriched by your questions. But I'll go through it one more time,
just as evidence that these observations are insufficiently supported,
so you and others looking on don't think I'm being evasive for not
answering, even though at some ponit I will start not answering and it
might otherwise look like I was just afraid to answer rather than
simply bored...

I sense this same sense of tedium in others responding to you. If I
were you, I would think hard about whether you've gotten what you
wanted from the valuable resource which is the patience of many who
have responded to you here, and I would ask myself, is it time to
modify my approach or ask the last few questions I'd like the answer
to before those resources shut down. Because you're offering very
little value and consuming great quantities of people as resources,
and I don't see that equation balancing for the extended time. Just a
personal suggestion.

Now, returning to your sort-of-scientific-looking observations above:

First, as to the question of the particular topics that come up: They
are typical early programming issues, but not necessarily evidence of
what people write macros about. So I'm not sure what you're
concluding about macros overall from these. If you want to make claims
about how people really use macros, you have to look in another place
than a forum where people ask lots of newbie questions. Here are
some things I've written macros for:

- A macro that took Augmented Transition Network (ATN) grammars as
arguments and expanded into a state machine for processing sentences
in the grammar. This would be possible, but a pain, to express in
functional notation because it would be full of words unrelated to
the domain.

- A macro that implemented FORTRAN-like call-by-reference semantics on a
body of code so that I could read in FORTRAN code and embed Lisp code
in the middle. This is a pain to do functionally both because of the
syntactic nuisance of having notations in the middle that were not
relevant to the domain code, and also because the proper expansion
needed to be mediated by code that made intelligent decisions about
whether to apply FORTRAN or Lisp semantics at any given point.

- Macros to implement facilities like LOOP and DEFMETHOD as part of language
substrate (emphasizing that large, non-trivial transformations might be
made from source code to compiled code).

- Macros that write macros that write macros (emphasizing the ability to
reflectively invoke Lisp as part of the expansion process).

- One-shot macros that are used just to initialize constant data
(emphasizing that macros are not a major programming project and are
often useful even for a one-off situation as a way of making a
single computation clearer).

- Macros that implement embedded languages.

- A macro language for manipulating HTML, that includes partial evaluation
so that structural representations of HTML that will do nothing more than
be written to a stream is done by string-out in many places rather than
first being consed.

Second, as to the question of there being more than one response that
comes in response to the newbie questions, I refer you to my previous
response on the issue of teaching people how to solve their own
problems. People often respond here about how to write things not
because they can't and don't create libraries, but because they want
newbies to know that they aren't at the mercy of the libraries. The
solutions are in range to mortals to write themselves.

Further, seeing many opinions on different ways to do something is not
symptomatic of failure. The movie industry is not in trouble because
people disagree on what the best movie is. It's _lack_ of choice, not
_choice_, that would be more symptomatic of a problem.

.

Relevant Pages

  • Re: Two questions together
    ... How powerful are the macros? ... > "programmable language" and as far as I know this feature is provided ... It is also said that one can hammer the Lisp so that ... I really love Lisp's syntax:) But I just want ...
    (comp.lang.lisp)
  • Re: A "killer" macro
    ... but then Ruby is dog slow anyway: ... Having notational convenience via macros plus efficiency is a big win ... From my perspective as a Ruby programmer learning Lisp, ... thought of having a more powerful language *and* orderof magnitude ...
    (comp.lang.lisp)
  • Re: A "killer" macro
    ... Or perhaps Lisp doesn't have one thing ultra- ... with a prefix language. ... the only thing that *really* sets Lisp apart is macros. ... Ruby and C# are very different. ...
    (comp.lang.lisp)
  • Re: macro for shorter array syntax
    ... reason I turned to Lisp is that many, or even most, people in the C++ ... it is also a good idea to be careful with adding new macros. ... Hence an ideal language for implementing an interpreter for Simulink models would allow one to define block types directly, like e.g. so: ... So the actual implementation of the functionality provided by define-node-type is mostly achieved through functional libraries, MOP hackery, etc., and it is indeed still possible to define new node types by hand via defclass, defmethod and various globally-defined macro helpers, but a node definition is much more concise. ...
    (comp.lang.lisp)
  • Re: The War On HLA
    ... If you're assuming that macros' only purpose is for "in-line" functions, ... languages demonstrate the ability of using macros to extend the language. ... I would ask why you're using Delphi in the first place. ... programming language (i.e., you can assign them to variables, ...
    (alt.lang.asm)
Quantcast