Python syntax in Lisp and Scheme

[Paolo Amoroso]

Re: Python syntax in Lisp and Scheme

[The original followup was to comp.lang.pytho n. But since Alex mostly
discusses Lisp features, and we probably both don't subscribe to each
other's group, I follow up to both of them]

Alex Martelli writes:
[color=blue]
> As in, no lisper will ever admit that a currently existing feature is
> considered a misfeature?-)[/color]

Paul Graham is possibly the best known such lisper. You may check the
documents about the Arc dialect at his site.


[Pascal Costanza][color=blue][color=green]
>> What makes you think that macros have farther reaching effects in this
>> regard than functions? If I call a method and pass it a function object,
>> I also don't know what the method will do with it.[/color]
>
> Of course not -- but it *cannot possibly* do what Gat's example of macros,
> WITH-MAINTAINED-CONDITION, is _claimed_ to do... "reason" about the
> condition it's meant to maintain (in his example a constraint on a variable
> named temperature), about the code over which it is to be maintained
> (three functions, or macros, that start, run, and stop the reactor),
> presumably infer from that code a model of how a reactor _works_, and
> rewrite the control code accordingly to ensure the condition _is_ in fact
> being maintained. A callable passed as a parameter is _atomic_ -- you
> call it zero or more times with arguments, and/or you store it somewhere
> for later calling, *THAT'S IT*. This is _trivially simple_ to document and
> reason about, compared to something that has the potential to dissect
> and alter the code it's passed to generate completely new one, most
> particularly when there are also implicit models of the physical world being
> inferred and reasoned about. Given that I've seen nobody say, for days!,[/color]

The word "reason" looks a bit too AI-sh: macros do much more mundane
things. If I correctly understand Erann Gat's example in the nuclear
reactor context, things would work like this.

Some domain primitives--e.g. for controlling temperature,
starting/stopping the reactor, etc.--would be written by, or with the
help of, nuclear reactor experts. These primitives, typically
implemented as ordinary functions/classes, would embody a model of how
the reactor works. At this point, there's nothing different with what
would be done with other languages.

Now suppose you have a code module in which you have to "maintain" a
certain condition in the reactor. By "maintain" I mean arrange a
possibly long sequence of calls to domain primitives in such a way
that the condition is maintained (e.g. call the function that starts
the reactor with appropriate arguments, call functions for getting
temperature sensor readings with other arguments, check the
temperature readings and take appropriate decisions based on the
values, etc.). I guess this is also what would be done with other
languages--and Lisp.

A WITH-MAINTAINED-CONDITION macro would just provide syntactic sugar
for that possibly long statement/expression sequence for "maintainin g"
the condition. That's it. It would typically accept parameters
describing the condition, and would generate the right sequence of
domain primitives with appropriate parameters.

WITH-MAINTAINED-CONDITION wouldn't have its own nuclear reactor model,
or other physical model. It would merely generate code templates,
mostly calls to ordinary functions, that the programmer would write
anyway (or put into a higher level function). Documenting such a macro
would be as easy as documenting the individual functions and/or an
equivalent function with internal calls to domain primitives.

Erann: is my understanding correct?

Alex: how would this way of using macros be dangerous?


Paolo
--
Paolo Amoroso <amoroso@mclink .it>

[Michele Dondi]

Re: Science is a human activity (was: Python syntax in Lisp and Scheme)

On Sat, 11 Oct 2003 10:37:33 -0500, David C. Ullrich
<ullrich@math.o kstate.edu> wrote:
[color=blue]
>It's certainly true that mathematicians do not _write_
>proofs in formal languages. But all the proofs that I'm
>aware of _could_ be formalized quite easily. Are you
>aware of any counterexamples to this? Things that
>mathematicia ns accept as correct proofs which are
>not clearly formalizable in, say, ZFC?[/color]

I am not claiming that it is a counterexample, but I've always met
with some difficulties imagining how the usual proof of Euler's
theorem about the number of corners, sides and faces of a polihedron
(correct terminology, BTW?) could be formalized. Also, however that
could be done, I feel an unsatisfactory feeling about how complex it
would be if compared to the conceptual simplicity of the proof itself.


Just a thought,
Michele
--[color=blue]
> Comments should say _why_ something is being done.[/color]
Oh? My comments always say what _really_ should have happened. :)
- Tore Aursand on comp.lang.perl. misc

[Pascal Bourguignon]

Re: Car and cdr (Re: Python syntax in Lisp and Scheme)


Pascal Costanza <costanza@web.d e> writes:[color=blue]
> Stephen Horne wrote:[color=green]
> > On Mon, 13 Oct 2003 15:28:57 +1300, "Greg Ewing (using
> > news.cis.dfn.de )" <g2h5dqi002@sne akemail.com> wrote:
> >[color=darkred]
> >>Andrew Dalke wrote:
> >>From that point of view, "car" and "cdr" are as good
> >>as anything![/color]
> > "left" and "right" - referring to 'subtrees'?[/color]
>
> Sure, why not?
>
> (defun left (tree)
> (car tree))
>
> (defun right (tree)
> (cdr tree))
>
> ;-)[/color]

Wrong:

(defun left (tree) (car (car tree)))
(defun right (tree) (cdr (car tree)))
(defun label (tree) (cdr tree))

[color=blue]
> Note: Why break anyone else's code just because you prefer a different
> vocabulary?
>
> (Yes, this is different from the Python mindset. What I have learnt
> from this thread is that the languages might seem similar on the
> technical level, but the "social" goals of the languages are vastly
> different.)[/color]

--
__Pascal_Bourgu ignon__

http://www.informatimago.com/

Do not adjust your mind, there is a fault in reality.

[Sean Ross]

Re: Code block literals

"John Roth" <newsgroups@jhr othjr.com> wrote in message
news:vol02ieh5i nade@news.super news.com...[color=blue]
>
> foobar = map(| x, y, z |
> astatement
> anotherstatemen t
> list1, list2, list3)
>
> I kind of like this better, except for one really unfortunate[/color]


Hi.
There was a short discussion along these lines back in June where I
mentioned the idea of using thunks, or something like that

http://groups.google.ca/groups?hl=en&lr=&ie=UTF-8&selm=vwsLa.7927%24OE2.1069377%40news20.bellglobal.com

The idea goes something like this:

Let's take imap as an example

def imap(function, *iterables):
iterables = map(iter, iterables)
while True:
args = [i.next() for i in iterables]
if function is None:
yield tuple(args)
else:
yield function(*args)


Here, you would use imap as follows:

mapped = imap(lambda x: x*x, sequence)

My idea would be to define imap as follows:

def imap(&function, *iterables):
iterables = map(iter, iterables)
while True:
args = [i.next() for i in iterables]
if function is None:
yield tuple(args)
else:
yield function(*args)

and the use could be more like this:

mapped = imap(sequence) with x:
print x # or whatever
return x*x

with x: ... creates a thunk, or anonymous function, which will be fed as an
argument to the imap function in place of the &function parameter.

I also had some hazy notion of having a two way feed. Where a thunk that is
associated with an iterator function could be fed arguments, and executed on
each iteration. Something like this:

y = 0
itertools.count (10) do with x:
y += x
print y


Anyway. I was thinking that the foobar example would look cleaner if the
block did not have to be included directly as an argument to the function
call, but could instead be associated with the function call, tacked onto
the end, like so

foobar = map(list1, list2, list3) with x, y, z:
astatement
anotherstatemen t

or maybe

foobar = map(list1, list2, list3) { (x, y, z):
astatement
anotherstatemen t
}

or, if we want to be explicit:

foobar = map(&thunk, list1, list2, list3) with x, y, z:
astatement
anotherstatemen t

so that we know where the thunk is being fed to as an argument. But, this
would probably limit the number of blocks you could pass to a function.

Anyway, as I've said, these are just some fuzzy little notions I've had in
passing. I'm not advocating their inclusion in the language or anything like
that. I just thought I'd mention them in case they're of some use, even if
they're just something to point to and say, "we definitely don't want that".

Sean

[Jon S. Anthony]

Re: Python syntax in Lisp and Scheme

Alex Martelli <aleaxit@yahoo. com> writes:

<typical unthinking stuff>


You're unrelenting tenacity to remain ignorant far exceeds any
inclination on my part to educate.

/Jon

[John Roth]

Re: Code block literals


"Sean Ross" <sross@connectm ail.carleton.ca > wrote in message
news:lqzib.4539 $cT6.106958@new s20.bellglobal. com...[color=blue]
> "John Roth" <newsgroups@jhr othjr.com> wrote in message
> news:vol02ieh5i nade@news.super news.com...[color=green]
> >[/color]
>
>
> Anyway. I was thinking that the foobar example would look cleaner if the
> block did not have to be included directly as an argument to the function
> call, but could instead be associated with the function call, tacked onto
> the end, like so
>
> foobar = map(list1, list2, list3) with x, y, z:
> astatement
> anotherstatemen t
>
> or maybe
>
> foobar = map(list1, list2, list3) { (x, y, z):
> astatement
> anotherstatemen t
> }
>
> or, if we want to be explicit:
>
> foobar = map(&thunk, list1, list2, list3) with x, y, z:
> astatement
> anotherstatemen t
>
> so that we know where the thunk is being fed to as an argument. But, this
> would probably limit the number of blocks you could pass to a function.[/color]

That's the basic problem with the Rubyesque syntaxes: it limits you to
one block per function, and it makes it an implicit parameter. I don't
know that that's bad per se - people who like Ruby don't seem to feel
it's a huge limitation. However, it simply doesn't slide into Python well.
That's why I used map() as my example: it's a function that almost has to
take another function to do anything useful, and that function is a specific
parameter.

John Roth
[color=blue]
> Sean[/color]

[Jon S. Anthony]

Re: Python syntax in Lisp and Scheme

Alex Martelli <aleaxit@yahoo. com> writes:
[color=blue]
> At the moment the only thing I am willing to denounce as idiotic are[color=green]
> > your clueless rants.[/color]
>
> Excellent! I interpret the old saying "you can judge a man by the quality
> of his enemies" differently than most do: I'm _overjoyed_ that my enemies
> are the scum of the earth, and you, sir [to use the word loosely], look as
> if you're fully qualified to join that self-selected company.[/color]

Whatever.

/Jon

[Stephen Horne]

Re: Car and cdr (Re: Python syntax in Lisp and Scheme)

On Mon, 13 Oct 2003 14:08:17 +0200, Pascal Costanza <costanza@web.d e>
wrote:
[color=blue]
>Stephen Horne wrote:[color=green]
>> On Mon, 13 Oct 2003 15:28:57 +1300, "Greg Ewing (using
>> news.cis.dfn.de )" <g2h5dqi002@sne akemail.com> wrote:[/color][/color]
[color=blue][color=green][color=darkred]
>>>From that point of view, "car" and "cdr" are as good
>>>as anything![/color]
>>
>>
>> "left" and "right" - referring to 'subtrees'?[/color][/color]
[color=blue]
>Note: Why break anyone else's code just because you prefer a different
>vocabulary?[/color]

I wasn't really suggesting a change to lisp - just asking if they
might be more appropriate names.

Actually, I have been having a nagging doubt about this.

I had a couple of phases when I learned some basic lisp, years ago. A
bit at college in the early nineties, and IIRC a bit when I was still
at school in the mid eighties. This was well before common lisp, I
believe.

Anyway, I'd swear 'car' and 'cdr' were considered backward
compatibility words, with the up-to-date words (of the time) being
'head' and 'tail'.

Maybe these are/were common site library conventions that never made
it into any standard?

This would make some sense. After all, 'head' and 'tail' actually
imply some things that are not always true. Those 'cons' thingies may
be trees rather than lists, and even if they are lists they could be
backwards (most of the items under the 'car' side with only one item
on the 'cdr' side) which is certainly not what I'd expect from 'head'
and 'tail'.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Peter Seibel]

Re: Python syntax in Lisp and Scheme

Alexander Schmolck <a.schmolck@gmx .net> writes:
[color=blue]
> Peter Seibel <peter@javamonk ey.com> writes:
>[color=green]
> > If for some reason you believe that macros will have a different
> > effect--perhaps decreasing simplicity, clarity, and directness then
> > I'm not surprised you disapprove of them. But I'm not sure why you'd
> > think they have that effect.[/color]
>
> Well, maybe he's seen things like IF*, MVB, RECEIVE, AIF, (or as far as
> simplicity is concerned LOOP)...?
>
> I'm not saying that macros always have ill-effects, but the actual
> examples above demonstrate that they *are* clearly used to by people
> to create idiosyncratic versions of standard functionality. Do you
> really think clarity, interoperabilit y or expressiveness is served
> if person A writes MULTIPLE-VALUE-BIND, person B MVB and person C
> RECEIVE?[/color]

Yes. But that's no different with macros than if someone decided that
they like BEGIN and END better than FIRST and REST (or CAR/CDR) and so wrote:

(defun begin (list) (first list))
(defun end (list) (rest list))

As almost everyone who has stuck up for Lisp-style macros has
said--they are just another way of creating abstractions and thus, by
necessity, allow for the possibility of people creating bad
abstractions. But if I come up with examples of bad functional
abstractions or poorly designed classes, are you going to abandon
functions and classes? Probably not. It really is the same thing.

[color=blue][color=green]
> > (deftest foo-tests ()
> > (check
> > (= (foo 1 2 3) 42)
> > (= (foo 4 5 6) 99)))
> >
> > Note that this is all about the problem domain, namely testing.[/color]
>
> I think the example isn't a bad one, in principle, in practice
> however I guess you could handle this superiorly in python.[/color]

Well, I admire your faith in Python. ;-)
[color=blue]
> I develop my testing code like this:
>
> # like python's unittest.TestCa se, only that it doesn't "disarm"
> # exceptions
> TestCase = awmstest.Permea bleTestCase
> #TestCase = unittest.TestCa se
>
> class BarTest(TestCas e):
> ...
> def test_foos(self) :
> assert foo(1,2,3) = 42
> assert foo(4,5,6) = 99
>
> Now if you run this in emacs/ipython with '@pdb on' a failure will
> raise an Exception, the debugger is entered and emacs automatically
> will jump to the right source file and line of code (I am not
> mistaken in thinking that you can't achieve this using emacs/CL,
> right?)[/color]

No, you're mistaken. In my test framework, test results are signaled
with "conditions " which are the Common Lisp version of exceptions. Run
in interactive mode, I will be dropped into the debugger at the point
the test case fails where I can use all the facilities of the debugger
to figure out what went wrong including jumping to the code in
question, examining stack framse, and then if I think I've figured out
the problem, I can redefine a function or two and retry the test case
and proceed with the rest of my test run with the fixed code.
(Obviously, after such a run you'd want to re-run the earlier tests to
make sure you hadn't regressed. If I really wanted, I could keep track
of the tests that had been run prior to such a change and offer to
rerun them automatically.)
[color=blue]
> and I can interactively inspect the stackframes and objects that
> were involved in the failure.[/color]

Yup. Me too. Can you retry the test case and proceed with the rest of
your tests?
[color=blue]
> I find this *very* handy (much handier than having the wrong result
> printed out, because in many cases I'm dealing with objects such as
> large arrays wich are not easily visualized).
>
> Once the code and test code works I can easily switch to mere
> reporting behavior (as described by andrew dalke) by uncommenting
> unittest.TestCa se back in.[/color]

Yup. That's really handy. I agree.

So, in all sincere curiosity, why did you assume that this couldn't be
done in Lisp. I really am interested as I'm writing a book about
Common Lisp and part of the challenge is dealing with people's
existing ideas about the language. Feel free to email me directly if
you consider that too far offtopic for c.l.python.

-Peter

--
Peter Seibel peter@javamonke y.com

Lisp is the red pill. -- John Fraser, comp.lang.lisp

[Dave Brueck]

Re: Python syntax in Lisp and Scheme

On Monday 13 October 2003 10:22 am, Jon S. Anthony wrote:[color=blue]
> Alex Martelli <aleaxit@yahoo. com> writes:
>
> <typical unthinking stuff>
>
>
> You're unrelenting tenacity to remain ignorant far exceeds any
> inclination on my part to educate.
>
> /Jon[/color]

+1 QOTW, under the comedy section.

-Dave

[Jock Cooper]

Re: Python syntax in Lisp and Scheme

Alexander Schmolck <a.schmolck@gmx .net> writes:
[color=blue]
> "Andrew Dalke" <adalke@mindspr ing.com> writes:[color=green]
> > The smartest people I know aren't programmers. What does
> > that say?[/color]
>
> I think this is vital point. CL's inaccessibility is painted as a feature of
> CL by many c.l.l denizens (keeps the unwashed masses out),[/color]

I have never seen this in c.l.l. - most seem to feel the inaccessibility
("ew the parens") are a necessary evil..
[color=blue]
> but IMO the CL
> community stunts and starves itself intellectually big time because CL is (I
> strongly suspect) an *extremely* unattractive language for smart people
> (unless they happen to be computer geeks).[/color]

Well Hofstadter seems pretty smart to me, I don't think he's a computer geek, and
he's pretty fascinated by Lisp. See G.E.B. and Metamagical Themas.

[Alexander Schmolck]

Re: Python syntax in Lisp and Scheme

prunesquallor@c omcast.net writes:[color=blue]
> Suppose I cut just one arm of a conditional. When I paste, it is
> unclear whether I intend for the code after the paste to be part of
> that arm, part of the else, or simply part of the same block.[/color]

Sorry, I have difficulties understanding what exactly you mean again. Would
you mind cutting and pasting something like the THEN/ELSE in the examples
below (say just marking the cut region with {}s and and where you'd like to
paste with @)?

(if CONDITION
THEN
ELSE)

if CONDITION:
THEN
else:
ELSE
[color=blue]
>[color=green][color=darkred]
> >> The fact that the information is replicated, and that there is nothing
> >> but programmer discipline keeping it consistent is a source of errors.[/color]
> >
> > Sure there is. Your editor and immediate visual feedback (no need to remember
> > to reindent after making the semantic changes).[/color]
>
> `immediate visual feedback' = programmer discipline
> Laxness at this point is a source of errors.[/color]

You got it backwards.
Not forgetting to press 'M-C-\' = programmer discipline.
Laxness at this point is a source of errors.

And indeed, people *do* have to be educated not to be lax when editing lisp -
newbies frequently get told in c.l.l or c.l.s that they should have reindented
their code because then they would have seen that they got their parens mixed
up.

OTOH, if you make an edit in python the result of this edit is immediately
obvious -- no mismatch between what you think it means and what your computer
thinks it means and thus no (extra) programmer discipline required.

Of course you need *some* basic level of discipline to not screw up your
source code when making edits -- but for all I can see at the moment (and know
from personal experience) it is *less* than what's required when you edit lisp
(I have provided a suggested way to edit this particular example in emacs for
python in my previous post -- you haven't provided an analoguous editing
operation for lisp with an explanation why it would be less error-prone)).

[color=blue][color=green][color=darkred]
> >> >> Yet the visual representation is not only identical between all of these, it
> >> >> cannot even be displayed.
> >> >
> >> > I don't understand what you mean. Could you maybe give a concrete example of
> >> > the information that can't be displayed?
> >>
> >> Sure. Here are five parens ))))) How much whitespace is there here:[/color]
> >
> > 10 spaces (which BTW I counted in emacs in just the same way that I'd count a
> > similar number of parens) -- but what has counting random trailing whitespace
> > got to do with anything?[/color]
>
> It is simply an illustration that there is no obvious glyph associated
> with whitespace, and you wanted a concrete example of something that can't
> be displayed.[/color]

No, I didn't want just *any* example of something that can't be displayed; I
wanted an example of something that can't be displayed and is *pertinent* to
our discussion (based on the Quinean assumption that you wouldn't have brought
up "things that can't be displayed" if they were completely besides the
point).

me:[color=blue][color=green][color=darkred]
> >> > People can't "read" '))))))))'.[/color][/color][/color]
[more dialog snipped][color=blue]
> I cannot read Abelson and Sussman's minds, but neither of them are
> ignorant of the vast variety of computer languages in the world.
> Nonetheless, given the opportunity to choose any of them for
> exposition, they have chosen lisp. Sussman went so far as to
> introduce lisp syntax into his book on classical mechanics.[/color]

Well the version of SICM *I've* seen predeominantly seems to use (infixy) math
notation, so maybe Sussman is a little less confident in the perspicuousness
of his brainchild than you (also cf. Iverson)?
[color=blue]
> Apparently he felt that not only *could* people read ')))))))', but
> that it was often *clearer* than the traditional notation.[/color]

Uhm, maybe we've got an different interpretation of 'read'?

If by 'read' you mean 'could hypothetically decipher', then yeah, sure with
enough effort and allowable margin of error, people can indeed 'read'
')))))))' and know that it amounts to 7 parens, and with even higher effort
and error margins they should even be able to figure out what each ')'
corresponds to.

I'm equally confident that you'd be in principle capable of 'deciphering' a
printout of my message in rot-13, modulo some errors.

I nontheless suspect I might hear complaints from you along the lines that
"couldn't read that" (if you had some reason to expect that its contents would
be of value to you in the first place).

I'm also pretty sure if I gave you version with each line accompagnied by its
rot-13 equivalent (and told you so) you'd just try to read the alphabetical
lines and ignore the rot-13 as noise (even if I told you that the rot-13 is
really the canonical version and the interspersed lines are just there for
visual convenience).

Now it's pretty much exactly the same for lisp code and trailing parens -- any
sane person in a normal setting will just try to ignore them as best as she
can and go by indentation instead -- despite the fact that doing so risks
misinterpreting the code, because the correspondence between parens and
indentation is unenforced and exists purely by convention (and lispers even
tend to have slightly different conventions, e.g. IF in CL/scheme) and C-M-\.

Reading *to me* means extracting the significant information from some written
representation and the ability to read is to do so with a reasonable amount of
effort. So in my diction, if a certain aspect of a written representation is
systematically and universally ignored by readers (at their peril) then surely
this aspect is unlikely to get points of maximum readability and one might
even conclude that people can't read so-and-so?

I don't personally think (properly formated) lisp reads that badly at all
(compared to say C++ or java) and you sure got the word-seperators right. But
to claim that using lisp-style parens are in better conformance with the
dictum above than python-style indentation frankly strikes me as a bit silly
(whatever other strengths and weaknesses these respective syntaxes might
have).

[color=blue]
> Obviously the indentation.
> But I'd notice the mismatch.[/color]

(Hmm, you or emacs?)
[color=blue]
> If I gave you a piece of python code jotted down on paper that (as these
> hypothetical examples usually are) for some reason was of vital importance
> but I accidentally misplaced the indentation -- how would you know?[/color]

Excellent point. But -- wait! Were it Lisp, how would I know that you didn't
intend e.g.

(if (bar watz) foo)

instead of

(if (bar) watz foo)

?

Like in so many fields of human endeavor, XML provides THE solution:

<if><bar/>watz foo</if>

So maybe we should both switch to waterlang, eh?


Moral: I really think your (stereoptypical ) argument that the possibility of
inconsistency between "user interpretation" and "machine interpretation" of a
certain syntax is a feature (because it introduces redundancy that can can be
used for error detection) requires a bit more work.


'as

p.s:

[oh, just to demonstrate that large groups of trailing parens actually do
occur and that, as has been mentioned, even perl has its uses]:

/usr/share/emacs/> perl -ne '$count++ if m/\){7}/; END{print "$count\n"; }' **/*el
2008

[Pekka P. Pirinen]

Re: Python syntax in Lisp and Scheme

Alex Martelli <aleaxit@yahoo. com> writes:[color=blue][color=green]
> > Can you give an example for the presumably dangerous things macros
> > supposedly can do that you have in mind?[/color]
>
> I have given this repeatedly: they can (and in fact have) tempt programmers
> using a language which offers macros (various versions of lisp) to, e.g.,
> "embed a domain specific language" right into the general purpose language.
> I.e., exactly the use which is claimed to be the ADVANTAGE of macros. I
> have seen computer scientists with modest grasp of integrated circuit design
> embed half-baked hardware-description languages (_at least_ one different
> incompatible such sublanguage per lab) right into the general-purpose
> language, and tout it at conferences as the holy grail[/color]

But this type of domain-specific language is not the advantage that
people mean. (After all, this type of task is rare.) They don't mean
a language for end-users, they mean a language for the programmers
themselves.

Any large software system builds up a domain-specific vocabulary;
e.g., a reactor-control system would have a function called
SHUTDOWN-REACTOR. In other languages, this vocabulary is usually
limited to constants, variables and functions, sometimes extending to
iterators (represented as a collection of the above); whereas, in
Lisp, it can include essentially any kind of language construct,
including ones that don't exist in the base language. E.g., a
reactor-control system can have a WITH-MAINTAINED-CONDITION context
(for the lack of a better word).

Whether or not the expansion of WITH-MAINTAINED-CONDITION is
particularly complex, the ability to indicate the scope of the
construct by enclosing a code block in a "body" is one of the most
useful aspects of this style of program construction. (This can be
done with HO functions in a fairly nice way, I know, assuming the
implementation of the construct does not need to examine or modify the
body code.)

Another very common language feature in these domain-specific
languages is a definer macro. When a number of similar entities need
to be described, a Lisp programmer would usually write a
DEFINE-<entity> macro which would generate all the boilerplate code
for initialization, registration, serialization, and whatever else
might be needed. This is also the way high-level interfaces to many
Lisp packages work: e.g., to use a Lisp GUI package you would
typically write something like
(define-window my-window (bordered-window)
:title "My Application"
:initial-width (/ (screen-width) 2)
...
:panes (sub-window ...)
)
and that would be 80% of the functionality. (Then you'd have to write
methods for the last 20%, which would be the hard bit.) Matthew
Danish' DEFINSTRUCTION macro in another subthread is a good example as
well.
--
Pekka P. Pirinen
Controlling complexity is the essence of computer programming.
- Kernighan

[Terry Reedy]

Re: Code block literals


"Sean Ross" <sross@connectm ail.carleton.ca > wrote in message
news:lqzib.4539 $cT6.106958@new s20.bellglobal. com...[color=blue]
> My idea would be to define imap as follows:
>
> def imap(&function, *iterables):
> iterables = map(iter, iterables)
> while True:
> args = [i.next() for i in iterables]
> if function is None:
> yield tuple(args)
> else:
> yield function(*args)
>
> and the use could be more like this:
>
> mapped = imap(sequence) with x:
> print x # or whatever
> return x*x
>
> with x: ... creates a thunk, or anonymous function, which will be[/color]
fed as an[color=blue]
> argument to the imap function in place of the &function parameter.[/color]

I find it counter-intuitive both that 'with xx' tacked on to the end
of an assignment statement should act +- like an lambda and even more
that the result should be fed back and up as an invisible arg in the
expression. For someone not 'accustomed' to this by Ruby, it seems
rather weird. I don't see any personal advantage over short lambdas
('func' would have been better) and defs, using 'f' as a default
fname.

....[color=blue]
> or, if we want to be explicit:
>
> foobar = map(&thunk, list1, list2, list3) with x, y, z:
> astatement
> anotherstatemen t[/color]

One could intuitively expect the invisible arg calculated lexically
after the call to be the last rather than first.
[color=blue]
> so that we know where the thunk is being fed to as an argument. But,[/color]
this[color=blue]
> would probably limit the number of blocks you could pass to a[/color]
function.[color=blue]
>
> Anyway, as I've said, these are just some fuzzy little notions I've[/color]
had in[color=blue]
> passing. I'm not advocating their inclusion in the language or[/color]
anything like[color=blue]
> that. I just thought I'd mention them in case they're of some use,[/color]
even if[color=blue]
> they're just something to point to and say, "we definitely don't[/color]
want that".

That is currently my opinion ;-)

Terry J. Reedy

[Kaz Kylheku]

Re: Python syntax in Lisp and Scheme

gregm@cs.uwa.ed u.au wrote in message news:<blr1cq$bb 1$1@enyo.uwa.ed u.au>...[color=blue]
> In comp.lang.funct ional Erann Gat <my-first-name.my-last-name@jpl.nasa.g ov> wrote:
> :> I can't see why a LISP programmer would even want to write a macro.
> : That's because you are approaching this with a fundamentally flawed
> : assumption. Macros are mainly not used to make the syntax prettier
> : (though they can be used for that). They are mainly used to add features
> : to the language that cannot be added as functions.
>
> Really? Turing-completeness and all that... I presume you mean "cannot[/color]

``Turing completeness and all that'' is an argument invoked by the
clueless.

Turing completeness doesn't say anything about how long something
takes to compute, or how easy it is to express some interesting
computation.

In the worst case, for you to get the behavior in some program I wrote
in language A in your less powerful (but Turing complete!) language B,
you might have to write an A interpreter or compiler, and then just
run my original program written in A! The problem is that you did not
actually find a way to *express* the A program in language B, only a
way to make its behavior unfold.

Moreover, you may have other problems, like difficulties in
communicating between the embedded A program and the surrounding B
code! These difficulties could be alleviated if you could write an A
*compiler* in B, a compiler which is integrated into your B compiler,
so that a mixture of A and B code is processed as one unit!

This is precisely what Lisp macros allow us to do: write compilers for
embedded languages, which operate together, all in the same pass.

So for instance an utterance in the embedded language can refer
directly to a local variable defined in a lexically surrounding
construct of the host language.
[color=blue]
> : DO-FILE-LINES and WITH-COLLECTOR are macros, and they can't be implemented
> : any other way because they take variable names and code as arguments.
>
> What does it mean to take a variable-name as an argument? How is that
> different to taking a pointer? What does it mean to take "code" as an
> argument? Is that different to taking a function as an argument?[/color]

Sheesh. A funtion is an object containing a program, and an
environment that establishes the meaning of entities like variables
for that program.

Code, in this context, means source code: a raw data structure
representing syntax.

Code can be analyzed, subject to transformations , and interpreted to
have arbitrary semantics.

A function can merely be invoked with arguments.

A compiler or interpreter for a functional language like Haskell still
has to deal with the representation of the program at some point: it
has to parse the source characters, recognize the syntax and translate
it into some meaning.

Lisp macros are part of the toolset that allow this translation itself
to be programmable. Thus you are not stuck with a fixed phrase
structure grammar with fixed semantics.

Nearly every programming language has macros, it's just that most of
them have a hard-coded set of ``factory defined'' macros in the form
of a fixed set of production rules with rigidly defined semantics.

What is a macro? It's a recognizer for syntax that implements some
kind of syntax-directed translation. I would argue that while (expr)
statement in the C language is a macro: it's a pattern that matches
a parse subtree that is tagged with the ``while'' token and translates
it into looping code, whose semantics call for the repeated testing of
the guarding expression, followed by execution of the statement if
that expression is true.