On Wed, Apr 17, 2013 at 8:06 PM, Arne Babenhauserheide <arne_...@web.de>wrote:
> At Wed, 17 Apr 2013 06:39:37 +0800,
> almkglor wrote:
> > Macros were not standard until R4RS, either (although most Scheme systems
> > pre-R4RS did have a Common Lisp-like unhygienic macro system). A better
>
> I did not know that… I had thought that lisps had macros from very early
> on.
>
Going seriously off-topic, but well... Lisp was originally just 'eval (in
fact, the first Lisp implementation was just an eval implementation in a
single page of code by John McCarthy). Very soon after that, macros were
invented. At Lisp spread, scoping was some sort of dynamic rather than
lexical, and people were not really concerned with large-scale programming,
and most Lisp's were Lisp-2's (function/macro/special form names were
separate from variables, so you could, say, have a 'if special form and an
'if variable binding).
Fast forward a couple decades and Sussman and Steele start dabbling on a
language called Schemer. It had lexical scope and was a Lisp-1, meaning
that function names were in the same namespace as values. This started
causing problems with the "ordinary" macros of most Lisp's available at the
time. In particular, consider a macro that expands to a function call to a
function named 'foo:
(define-macro (example x)
`(foo ,x))
and consider what happens when it's used in a context where 'foo is bound
locally:
(let ((foo #t))
(example foo))
==>
(let ((foo #t))
(foo foo))
On a Lisp-2, (foo foo) means "call the globally-bound function named 'foo
with the current value of the variable 'foo". Common Lisp augments this
further with an excellent package system that essentially changes (?) a
symbol's identity - 'foo in one package does not evaluate to the same
symbol as 'foo in another package unless it's been imported (if I
understood Common Lisp correctly, LOL). In a Lisp-1 like Scheme, it means
"call the current value of the variable 'foo with itself." Schemers also
prefer not to use Common Lisp's package system, often using lexical binding
to provide some kind of package system.
This lead to a lot of research into "hygienic macro expanders", which I
*think* is not yet *quite* resolved today (there are two main branches of
hygienic macro expanders, the syntax-case branch and the
syntactic-closures/explicit-renaming branches, the syntax-rules system can
be implemented on top of either, Andre van Tonder did an implementation
that supposedly implements both syntax-case and explicit-renaming (but not
syntactic-closures, I think) but I don't see (?) it used often), except
that most users seem to prefer the syntax-case branch, but the Scheme
implementers (?) seem to prefer syntactic-closures/explicit-renaming (which
makes sense because syntax-case needs some integration into your
compiler/interpreter, and it's somewhat harder to get a *simple*
s-expression that is the macro-expansion of the syntax-case output,
syntax-case output has to be a somewhat richer AST; van Tonder's attempt I
think restricts the special annotations only to symbols, whereas
syntax-case as originally conceived had annotations infecting all nodes to
prevent the O(n^2) behavior of a similar but simpler ancestor of
syntax-case). In fact, the inclusion of syntax-case in the R6RS branch
seems to be a minor contributor to its de facto rejection.
>
> > > Can’t they simply use the “ignore whitespace change” options to diff?
> > >
> >
> > Err, that would have to be in *patch*, not in diff. But it would mess up
> > the indentation afterwards if you applied an indented patch into an
> > unindented source (entirely new lines in the code would be indented more
> > than their surroundings) or vice versa. So it's less ideal for the
> > maintainer, since applying patches becomes more complex. Simpler to just
> > start all defines at indent 0, and for code in a module-is-one-datum
> > system, just wrap all the defines in the module annotation without
> > disturbing their indentations.
>
> That’s right, yes… I think it hurts clarity (you cannot see at one
> glance whether the define is part of the module or not), but I can see
> the convenience advantage for maintaining the code.
>
Most coders would put a single module's code inside a single file, with
one-file-per-module. So it's not an issue, if it's in the file, it's part
of the module, indentation or no indentation
>
> Can the module reuse defines outside the module to avoid that?
>
>
Most module systems allow importing another module's exported bindings, and
few might be able to import "global" bindings, whatever "global" might mean
for your Scheme system's module system.
Sincerely,
AmkG
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
