Based on recent discussions with Pascal and Kent, I just got (semi)
hygienic macros to work in my lexicon system. (I figure since Kenny
plugs cells here all the time it's OK for me to do the same for
lexicons.) I can now do this:
? (ldefun myfn (x) (list 'myfn x))
MYFN
? (ldefmacro mymacro (x) `(list (myfn ',x) (,myfn ',x)))
MYMACRO
? (flet ((myfn (x) (list 'local-myfn x))) (mymacro foo))
((LOCAL-MYFN FOO) (MYFN FOO))
?
Cool, huh?
I call them semi-hygienic because they only properly capture global
lexical bindings, not local ones, and you still have to insert gensyms
manually where needed. But this was the last thing I needed to make
lexicons really ready for prime time. It is now possible to write safe
modular macros in Common Lisp without packages. No more symbol name
conflicts!
I was just so excited I had to tell someone. :-)
rg
In article
<····································@h25g2000hsf.googlegroups.com>,
"Leslie P. Polzer" <·············@gmx.net> wrote:
> > Cool, huh?
>
> > I was just so excited I had to tell someone. :-)
>
>
> So... where do we get it?
Sneak preview version is available at:
http://www.flownet.com/ron/lisp
but it's not well tested and the documentation is still pretty sketchy.
There's a now out-of-date draft of a paper there, and a tiny bit of
example code embedded in the file, but not much else. I should have a
primer done for a grand opening this weekend. (You'll need
utilities.lisp and dictionary.lisp as well. Note if you've previously
downloaded my utilities file, you'll need the new version. The last
version had a critical bug in the AIF macro that will cause lexicons to
fail badly.)
If you do decide to take the plunge I'd appreciate any feedback.
rg
From: Maciej Katafiasz
Subject: Re: Woohoo! My macros are now (semi) hygienic
Date:
Message-ID: <fpqdo8$ktl$3@news.net.uni-c.dk>
Den Fri, 22 Feb 2008 10:02:56 -0800 skrev Ron Garret:
>> So... where do we get it?
>
> Sneak preview version is available at:
>
> http://www.flownet.com/ron/lisp
>
> but it's not well tested and the documentation is still pretty sketchy.
> There's a now out-of-date draft of a paper there, and a tiny bit of
> example code embedded in the file, but not much else. I should have a
> primer done for a grand opening this weekend. (You'll need
> utilities.lisp and dictionary.lisp as well. Note if you've previously
> downloaded my utilities file, you'll need the new version. The last
> version had a critical bug in the AIF macro that will cause lexicons to
> fail badly.)
This looks interesting. I've read about your locales previously, but
didn't understand them enough to be interested in, now I got a better
grasp, and it seems useful. Certainly not having to fight with mistakenly
interned symbols causing conflicts is a useful property.
> If you do decide to take the plunge I'd appreciate any feedback.
Will do. How far away are LDEFCLASS and LDEFMETHOD from being useful?
Cheers,
Maciej
In article <············@news.net.uni-c.dk>,
Maciej Katafiasz <········@gmail.com> wrote:
> > If you do decide to take the plunge I'd appreciate any feedback.
>
> Will do. How far away are LDEFCLASS and LDEFMETHOD from being useful?
Your guess is as good as mine at this point. Try them and tell me. :-)
(As far as I know they should be working, but they have not been tested.
That's part of what's holding up the official release.)
rg
From: Maciej Katafiasz
Subject: Re: Woohoo! My macros are now (semi) hygienic
Date:
Message-ID: <fpt0eh$ktl$4@news.net.uni-c.dk>
Den Fri, 22 Feb 2008 10:02:56 -0800 skrev Ron Garret:
> Sneak preview version is available at:
>
> http://www.flownet.com/ron/lisp
>
> but it's not well tested and the documentation is still pretty sketchy.
> There's a now out-of-date draft of a paper there, and a tiny bit of
> example code embedded in the file, but not much else. I should have a
> primer done for a grand opening this weekend. (You'll need
> utilities.lisp and dictionary.lisp as well. Note if you've previously
> downloaded my utilities file, you'll need the new version. The last
> version had a critical bug in the AIF macro that will cause lexicons to
> fail badly.)
>
> If you do decide to take the plunge I'd appreciate any feedback.
When I try to load it, SBCL is entirely unhappy about utilities.lisp
trying to do things in :cl, which is a locked package:
Lock on package COMMON-LISP violated when defining a
setf-expander for SUBSEQ.
[Condition of type SB-EXT:SYMBOL-PACKAGE-LOCKED-ERROR]
See also:
SBCL Manual, Package Locks [:node]
Common Lisp Hyperspec, 11.1.2.1.2 [:section]
Cheers,
Maciej
In article <············@news.net.uni-c.dk>,
Maciej Katafiasz <········@gmail.com> wrote:
> Den Fri, 22 Feb 2008 10:02:56 -0800 skrev Ron Garret:
>
> > Sneak preview version is available at:
> >
> > http://www.flownet.com/ron/lisp
> >
> > but it's not well tested and the documentation is still pretty sketchy.
> > There's a now out-of-date draft of a paper there, and a tiny bit of
> > example code embedded in the file, but not much else. I should have a
> > primer done for a grand opening this weekend. (You'll need
> > utilities.lisp and dictionary.lisp as well. Note if you've previously
> > downloaded my utilities file, you'll need the new version. The last
> > version had a critical bug in the AIF macro that will cause lexicons to
> > fail badly.)
> >
> > If you do decide to take the plunge I'd appreciate any feedback.
>
> When I try to load it, SBCL is entirely unhappy about utilities.lisp
> trying to do things in :cl, which is a locked package:
>
> Lock on package COMMON-LISP violated when defining a
> setf-expander for SUBSEQ.
> [Condition of type SB-EXT:SYMBOL-PACKAGE-LOCKED-ERROR]
> See also:
> SBCL Manual, Package Locks [:node]
> Common Lisp Hyperspec, 11.1.2.1.2 [:section]
Like I said, this code is not officially released. That's one of the
reasons.
BTW, there I have uncovered at least one serious bug in the current
release of lexicons, so there's really no point in looking at it unless
you want to hack on it.
(Utilities used to be in its own package. The annoyance of having to
maintain the export list is one of the things that motivated me to write
lexicons.)
rg
In article <·······························@news.gha.chartermi.net>,
Ron Garret <·········@flownet.com> wrote:
> In article <············@news.net.uni-c.dk>,
> Maciej Katafiasz <········@gmail.com> wrote:
>
> > Den Fri, 22 Feb 2008 10:02:56 -0800 skrev Ron Garret:
> >
> > > Sneak preview version is available at:
> > >
> > > http://www.flownet.com/ron/lisp
> > >
> > > but it's not well tested and the documentation is still pretty sketchy.
> > > There's a now out-of-date draft of a paper there, and a tiny bit of
> > > example code embedded in the file, but not much else. I should have a
> > > primer done for a grand opening this weekend. (You'll need
> > > utilities.lisp and dictionary.lisp as well. Note if you've previously
> > > downloaded my utilities file, you'll need the new version. The last
> > > version had a critical bug in the AIF macro that will cause lexicons to
> > > fail badly.)
> > >
> > > If you do decide to take the plunge I'd appreciate any feedback.
> >
> > When I try to load it, SBCL is entirely unhappy about utilities.lisp
> > trying to do things in :cl, which is a locked package:
> >
> > Lock on package COMMON-LISP violated when defining a
> > setf-expander for SUBSEQ.
> > [Condition of type SB-EXT:SYMBOL-PACKAGE-LOCKED-ERROR]
> > See also:
> > SBCL Manual, Package Locks [:node]
> > Common Lisp Hyperspec, 11.1.2.1.2 [:section]
>
> Like I said, this code is not officially released. That's one of the
> reasons.
I've uploaded a new version of utilities that loads under both SBCL and
CLisp. (Whether it actually works or not is another question.)
Seriously, though, if you want it to Just Work you'll have to wait a day
or two.
rg
On Feb 22, 12:46 am, Ron Garret <·········@flownet.com> wrote:
> It is now possible to write safe modular macros in Common Lisp without packages.
But I don't want to write anything other than throwaway code without
using packages.
I don't use packages just for the sake of macros.
> No more symbol name conflicts!
Is that so?
;; in Bob's library:
(ldefun myfun ...)
;; in Jack's library
(ldefun myfun ...)
Load both and no conflict? We can dispense with packages now?
In article
<····································@s19g2000prg.googlegroups.com>,
Kaz Kylheku <········@gmail.com> wrote:
> On Feb 22, 12:46�am, Ron Garret <·········@flownet.com> wrote:
> > It is now possible to write safe modular macros in Common Lisp without
> > packages.
>
> But I don't want to write anything other than throwaway code without
> using packages.
No one is holding a gun to your head. But you might want to try it
before you decide you don't like it.
> >�No more symbol name conflicts!
>
> Is that so?
>
> ;; in Bob's library:
>
> (ldefun myfun ...)
>
> ;; in Jack's library
>
> (ldefun myfun ...)
>
> Load both and no conflict?
That's right. :-) Lexicons used as libraries have an explicit
ordering, and so one binding will always shadow the other. (The
shadowed binding is still accessible though, but you have to do a little
extra typing to get to it.)
> We can dispense with packages now?
You can if you choose to. All of the problems that packages solve are
also solved by lexicons, and I believe that some people will find
lexicons a more intuitively appealing computational model. But it's not
an either-or proposition. Lexicons are built on top of Common Lisp, so
you can use packages and lexicons together if you want to. (In fact,
one of the design options I was considering was to automatically
associate a package with each lexicon so that symbols corresponding to
bindings were created and maintained automatically. I haven't done that
in the current version, but if people want that it's pretty easy to do.)
rg
From: Kent M Pitman
Subject: Re: Woohoo! My macros are now (semi) hygienic
Date:
Message-ID: <ubq68u2c1.fsf@nhplace.com>
Kaz Kylheku <········@gmail.com> writes:
> ;; in Bob's library:
>
> (ldefun myfun ...)
>
> ;; in Jack's library
>
> (ldefun myfun ...)
>
> Load both and no conflict? We can dispense with packages now?
Yep. Just one hitch: We can't call each other's code any more. :)
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> Kaz Kylheku <········@gmail.com> writes:
>
> > ;; in Bob's library:
> >
> > (ldefun myfun ...)
> >
> > ;; in Jack's library
> >
> > (ldefun myfun ...)
> >
> > Load both and no conflict? We can dispense with packages now?
>
> Yep. Just one hitch: We can't call each other's code any more. :)
Of course you can.
Why do you feel the need to take pot shots at my work before you've even
bothered to look at it?
rg
In article <·······························@news.gha.chartermi.net>,
Ron Garret <·········@flownet.com> wrote:
> In article <·············@nhplace.com>,
> Kent M Pitman <······@nhplace.com> wrote:
>
> > Kaz Kylheku <········@gmail.com> writes:
> >
> > > ;; in Bob's library:
> > >
> > > (ldefun myfun ...)
> > >
> > > ;; in Jack's library
> > >
> > > (ldefun myfun ...)
> > >
> > > Load both and no conflict? We can dispense with packages now?
> >
> > Yep. Just one hitch: We can't call each other's code any more. :)
>
> Of course you can.
? (make-lexicon "BOB")
#<lexicon BOB>
? (make-lexicon "JACK")
#<lexicon JACK>
? (in-lexicon "BOB")
#<lexicon BOB>
? (ldefun myfn () 'bob-myfn)
MYFN
? (in-lexicon "JACK")
#<lexicon JACK>
? (ldefun myfn () 'jack-myfn)
MYFN
? (in-lexicon "BOB")
#<lexicon BOB>
? (limport "JACK" myfn :as jack-myfn)
T
? (myfn)
BOB-MYFN
? (jack-myfn)
JACK-MYFN
? (in-lexicon "JACK")
#<lexicon JACK>
? (limport "BOB" myfn :as bob-myfn)
T
? (myfn)
JACK-MYFN
? (bob-myfn)
BOB-MYFN
?
? (make-lexicon "MYLEX")
#<lexicon MYLEX>
? (in-lexicon "MYLEX")
#<lexicon MYLEX>
? (use-lexicon "BOB")
(#<lexicon BOB>)
? (use-lexicon "JACK")
(#<lexicon JACK> #<lexicon BOB>)
; Note no errors. Later bindings automatically shadow earlier ones.
? (myfn)
JACK-MYFN
; To access a shadowed binding all you have to do is give it an alias.
? (limport "BOB" myfn :as bob-myfn)
T
? (bob-myfn)
BOB-MYFN
? (myfn)
JACK-MYFN
; LIMPORT imports (lexical) bindings, not values, so when Bob changes his
; code all the users see the changes. (Contrast this with Python.)
? (in-lexicon "BOB")
#<lexicon BOB>
? (ldefun myfn () 'new-bob-myfn)
MYFN
? (in-lexicon "MYLEX")
#<lexicon MYLEX>
? (bob-myfn)
NEW-BOB-MYFN
Note that if you're going to try this yourself, there was a bug in
LIMPORT in version 0.2. I've uploaded a fix as version 0.3, but one of
the things on my todo list before I officially release this code is to
get it under proper version control.
rg
Ron Garret wrote:
> In article <·············@nhplace.com>,
> Kent M Pitman <······@nhplace.com> wrote:
>> Yep. Just one hitch: We can't call each other's code any more. :)
>
> Of course you can.
>
> Why do you feel the need to take pot shots at my work before you've even
> bothered to look at it?
But isn't that why the internet was invented? That and to be able to
compare anyone and anything to Hitler at the speed of light. At least
he put a smiley at the end of it. I think you may have timed your press
release poorly, though. Arc already has all of the "how do you know you
don't like it if you've never even tried it" ("It came to me in a
dream!") cycles taken.
From: Kent M Pitman
Subject: Re: Woohoo! My macros are now (semi) hygienic
Date:
Message-ID: <ufxvkinj1.fsf@nhplace.com>
Ron Garret <·········@flownet.com> writes:
> Kent M Pitman <······@nhplace.com> wrote: [...]
>
> > Kaz Kylheku <········@gmail.com> writes: [...]
>
> > > Load both and no conflict? We can dispense with packages now?
> >
> > Yep. Just one hitch: We can't call each other's code any more. :)
>
> Of course you can.
>
> Why do you feel the need to take pot shots at my work before you've even
> bothered to look at it?
It wasn't a pot shot. It was just a joke. That's why I put the smiley.
My normal rule of thumb is not to make jokes that are too easily confused
with the truth. Somewhat of a subjective test, but usually it works close
enough. Since it didn't occur to me that anyone would take me seriously
that you would build a tool with so obvious and fundamental a flaw, it
didn't seem to me to be an issue. But if you want to ignore the fact that
my making the joke tries to give you some credit, and argue that I should
not have given you such credit, I guess you can.
I _do_ have some questions about whether your tool's so-called
semi-hygienic nature will turn out to be something useful. It isn't
an example of perfect marketing, but I say that knowing that I am a
proponent of something I sometimes call "substandards" ... so I know
that names aren't always what they seem to be. My questions are just
that: questions ... not conclusions. I'm withholding judgment.
If the tool has the bug I jokingly suggested, it'll probably turn out
to be a silly oversight of no importance. If I dislike the tool, I
expect it to be for other reasons.
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > Kent M Pitman <······@nhplace.com> wrote: [...]
> >
> > > Kaz Kylheku <········@gmail.com> writes: [...]
> >
> > > > Load both and no conflict? We can dispense with packages now?
> > >
> > > Yep. Just one hitch: We can't call each other's code any more. :)
> >
> > Of course you can.
> >
> > Why do you feel the need to take pot shots at my work before you've even
> > bothered to look at it?
>
> It wasn't a pot shot. It was just a joke.
The two are not mutually exclusive. And in the context of Kaz's
less-than-encouraging remarks it sure felt like you were piling on.
But...
> That's why I put the smiley.
I apologize if I misinterpreted your intentions.
> Since it didn't occur to me that anyone would take me seriously
> that you would build a tool with so obvious and fundamental a flaw
Kaz seems to take that possibility quite seriously.
> I _do_ have some questions about whether your tool's so-called
> semi-hygienic nature will turn out to be something useful.
That is an open question. But it was the one issue that kept me from
releasing Lexicons before now (and I've been working on them for a long,
long time) because I knew that without something like this Lexicons were
fatally flawed. Whether this really fixes the problem remains to be
seen, but at least it's there's no reason that I'm aware of now for it
to be DOA.
rg
I'm very interested in this stuff. I don't have time for checking it
out
right now, though. What will we get when you officially release it?
Could you make up a quick comparison of what package problems it will
solve?
Thanks a lot! :)
Leslie
In article
<····································@28g2000hsw.googlegroups.com>,
"Leslie P. Polzer" <·············@gmx.net> wrote:
> I'm very interested in this stuff. I don't have time for checking it
> out
> right now, though. What will we get when you officially release it?
I'm shooting for Monday. It's mostly a matter of writing a primer, and
deleting some old code that doesn't work any more. And testing.
> Could you make up a quick comparison of what package problems it will
> solve?
There are two main problems (or maybe I should call them annoyances)
with packages that Lexicons were designed to solve:
1. The need to manually build and maintain exported symbol lists
2. The fact that the reader causes side-effects which, if packages have
not been properly set up, can be difficult to undo. For example, if you
load some code that relies on a package before that package has been
used then you end up with interned symbols in the using package that now
must all be uninterned before the package can be used.
I'm actually particularly proud of the solution to problem #2 because
lexicons can "defer" lexical bindings, e.g.:
? (in-lexicon "LIBRARY")
#<lexicon LIBRARY>
? (ldefun library-function () 'library)
LIBRARY-FUNCTION
? (in-lexicon "MYLEX")
#<lexicon MYLEX>
? (ldefun my-fn () (library-function))
; Warning: Defering lexical binding of LIBRARY-FUNCTION
; While executing: *REF, in process Listener(117).
MY-FN
; Oops, forgot to import the library
? (use-lexicon "LIBRARY")
(#<lexicon LIBRARY> #<lexicon JACK> #<lexicon BOB>)
? (my-fn)
Resolving lexical binding of LIBRARY-FUNCTION
LIBRARY
?
So for this common class of error, not only do you not have to clean up
your package, but most of the time you don't even have to recompile your
code.
Contrast that with the package situation:
? (in-package "LIBRARY")
#<Package "LIBRARY">
? (defun pkg-library-function () 'pkg-library-function)
PKG-LIBRARY-FUNCTION
? (export 'pkg-library-function)
T
? (in-package :cl-user)
#<Package "COMMON-LISP-USER">
? (defun pkg-my-fn () (pkg-library-function))
;Compiler warnings :
; Undefined function PKG-LIBRARY-FUNCTION, in PKG-MY-FN.
PKG-MY-FN
? (use-package "LIBRARY")
> Error: Using #<Package "LIBRARY"> in #<Package "COMMON-LISP-USER">
> would cause name conflicts with symbols already present in that package:
> PKG-LIBRARY-FUNCTION LIBRARY:PKG-LIBRARY-FUNCTION
> LIBRARY-FUNCTION LIBRARY:LIBRARY-FUNCTION
>
> While executing: CCL::USE-PACKAGE-1, in process Listener(117).
> Type :GO to continue, :POP to abort, :R for a list of available restarts.
> If continued: Try again to use #<Package "LIBRARY"> in #<Package "COMMON-LISP-USER">
> Type :? for other options.
1>
This is not that hard to recover from once you know what you're doing,
but it can be quite vexing for newcomers.
rg
On Feb 23, 5:50 pm, Ron Garret <·········@flownet.com> wrote:
> There are two main problems (or maybe I should call them annoyances)
> with packages that Lexicons were designed to solve:
>
> 1. The need to manually build and maintain exported symbol lists
>
> 2. The fact that the reader causes side-effects which, if packages have
> not been properly set up, can be difficult to undo. For example, if you
> load some code that relies on a package before that package has been
> used then you end up with interned symbols in the using package that now
> must all be uninterned before the package can be used.
These are two problems that bug me, too.
That puts me into the target audience group, I guess -- go for it,
Ron :)
On Feb 23, 8:50 am, Ron Garret <·········@flownet.com> wrote:
> In article
> <····································@28g2000hsw.googlegroups.com>,
> "Leslie P. Polzer" <·············@gmx.net> wrote:
>
> > Could you make up a quick comparison of what package problems it will
> > solve?
>
> There are two main problems (or maybe I should call them annoyances)
> with packages that Lexicons were designed to solve:
>
> 1. The need to manually build and maintain exported symbol lists
Automatically bringing together arbitrary symbols from different
namespaces into one scope is braindamaged. Only in rare situations
where the source namespace is very stable can you do a wholesale
import of its bindings without naming the specific names that you
want.
It sounds like you're basically reinventing something which has the
semantics of the Modula-2 WITH statement.
VAR foo : foo_record, bar : bar_record;
WITH foo DO
WITH bar DO
(* ... access members of bar and foo using short names ... *)
END;
END;
Above, there is also no need to maintain any export lists. Why?
Because all of the members of a record are considered ``exported''
under the WITH operator. When you add a new member to the record type
definition, it's automatically visible in all WITH statements which
involve that record type, everywhere in the program. Both foo_record
and bar_record each in fact constitute a lexicon where certain names
have bindings; these are instantiated in the instances instances foo
and bar. Thus WITH performs an import of these namespaces into the
current scope.
Suppose foo has a member x that you access in the DO block, and bar
doesn't have any member called x. So in that lexical scope, the name x
refers to foo.x. Suppose that someone now edits the type definition of
bar_record such that it acquires a member called x. Now when you
recompile the WITH statement above, the expression x suddenly refers
to bar.x! If bar.x is suitably typed, there will be no compiler
error. Unintentional shadowing of a local variable can also take
place: bad hygiene.
Modula-3 has a completely different WITH, a sane form which resembles
SYMBOL-MACROLET. The Modula-3 with creates lexical aliases for
expressions; only those names are introduced into the scope which are
explicitly listed in the WITH construct.
It's C++ that's carrying the torch now for the braindamaged WITH, in
the form of class scope.
int x;
int abc::foo()
{
// ``lexicon'' of abc class ``imported'' here.
return x + y; // y is abc::y, x is ::x.
}
If class is edited so that x is a member, now the expression returns
the member x. If you want the global x, you have to discover this
problem and then add the qualification ::x. You can also be clear that
you really want the member by writing this->x or abc::x.
Python and CL get this right; the object is passed explicitly, and you
write some expression that requests its member explicitly. No
automatic lexicon-munging.
The Common Lisp WITH-SLOTS is also sane, since you explicitly list the
bindings that you are importing.
In article
<····································@n77g2000hse.googlegroups.com>,
Kaz Kylheku <········@gmail.com> wrote:
> On Feb 23, 8:50 am, Ron Garret <·········@flownet.com> wrote:
> > In article
> > <····································@28g2000hsw.googlegroups.com>,
> > "Leslie P. Polzer" <·············@gmx.net> wrote:
> >
> > > Could you make up a quick comparison of what package problems it will
> > > solve?
> >
> > There are two main problems (or maybe I should call them annoyances)
> > with packages that Lexicons were designed to solve:
> >
> > 1. The need to manually build and maintain exported symbol lists
>
> Automatically bringing together arbitrary symbols from different
> namespaces into one scope is braindamaged. Only in rare situations
> where the source namespace is very stable can you do a wholesale
> import of its bindings without naming the specific names that you
> want.
I suppose you consider USE-PACKAGE brain-damaged then.
BTW, just because you aren't manually maintaing an export list doesn't
mean you don't have any control of the visibility of bindings. Lexicons
do provide the functional equivalent of export lists, but they are
implemented in a way that doesn't require the programmer to manually
maintain the list. But to encourage you to actually go and look at the
documentation (once I finish it of course, which should be in an hour or
two) I'm not going to tell you what it is :-)
> It sounds like you're basically reinventing something which has the
> semantics of the Modula-2 WITH statement.
>
> VAR foo : foo_record, bar : bar_record;
>
> WITH foo DO
> WITH bar DO
> (* ... access members of bar and foo using short names ... *)
> END;
> END;
>
> Above, there is also no need to maintain any export lists. Why?
> Because all of the members of a record are considered ``exported''
> under the WITH operator. When you add a new member to the record type
> definition, it's automatically visible in all WITH statements which
> involve that record type, everywhere in the program. Both foo_record
> and bar_record each in fact constitute a lexicon where certain names
> have bindings; these are instantiated in the instances instances foo
> and bar. Thus WITH performs an import of these namespaces into the
> current scope.
>
> Suppose foo has a member x that you access in the DO block, and bar
> doesn't have any member called x. So in that lexical scope, the name x
> refers to foo.x. Suppose that someone now edits the type definition of
> bar_record such that it acquires a member called x. Now when you
> recompile the WITH statement above, the expression x suddenly refers
> to bar.x! If bar.x is suitably typed, there will be no compiler
> error. Unintentional shadowing of a local variable can also take
> place: bad hygiene.
Yep. Power tools can hurt you if they are not used judiciously.
> Modula-3 has a completely different WITH, a sane form which resembles
> SYMBOL-MACROLET. The Modula-3 with creates lexical aliases for
> expressions; only those names are introduced into the scope which are
> explicitly listed in the WITH construct.
You can do that with lexicons too if you choose to.
> It's C++ that's carrying the torch now for the braindamaged WITH, in
> the form of class scope.
>
> int x;
>
> int abc::foo()
> {
> // ``lexicon'' of abc class ``imported'' here.
> return x + y; // y is abc::y, x is ::x.
> }
>
> If class is edited so that x is a member, now the expression returns
> the member x. If you want the global x, you have to discover this
> problem and then add the qualification ::x. You can also be clear that
> you really want the member by writing this->x or abc::x.
If you consider the class definition to be part of the lexical scope of
the method (which is not an unreasonable position) then this is no
different from changing a free variable to a bound variable by wrapping
a form in an additional binding construct.
It seems to me that you are simply making the observation that the
semantics of free references can be changed by making changes in the
surrounding code. Yep, that's true, but it's not exactly news.
I am beginning to understand why Paul Graham doesn't take criticism of
Arc from the CL community very seriously.
> Python and CL get this right; the object is passed explicitly, and you
> write some expression that requests its member explicitly. No
> automatic lexicon-munging.
>
> The Common Lisp WITH-SLOTS is also sane, since you explicitly list the
> bindings that you are importing.
Not that I really expect to convince you of anything (including the
advisability of actually studying something before you criticize it),
but lexicons apply only to global bindings (i.e. free references). They
do not change the semantics of CLOS slot reference at all.
rg
Ron Garret wrote:
>
> I suppose you consider USE-PACKAGE brain-damaged then.
>
Actually this is one of the things that took me quite a while to get.
This meaning 'use-package foo' isn't really about 'using' the package foo.
Cause to 'use a package' all I have to do is load and call the stuff i need
like
(require 'foo) ; or whatever approrpiate like asdf:load
(foo::x)
(foo:y)
Calling use-package is not necessary
This is a newbee POV and your 'idiots guide to packages' helped a lot.
So personally I think other than the CL package, I wouldn't 'use-package' any package till
I can say I am not a newbee.
All the books and the hyperspec define/didact all of these package related functions but I don't
think any of them really point this out.
Posting in case this helps another newbee
-Antony
P.S.: can i use didact as a verb
In article <································@comcast.com>,
lisp linux <·········@lisp.linux> wrote:
> Ron Garret wrote:
> >
> > I suppose you consider USE-PACKAGE brain-damaged then.
> >
> Actually this is one of the things that took me quite a while to get.
> This meaning 'use-package foo' isn't really about 'using' the package foo.
>
> Cause to 'use a package' all I have to do is load and call the stuff i need
> like
> (require 'foo) ; or whatever approrpiate like asdf:load
> (foo::x)
> (foo:y)
> Calling use-package is not necessary
Sure, but having to type foo:: all the time can get rather tedious,
don't you think?
They can get particularly tedious if you want to use something standard
that doesn't live in a standard package, e.g.:
(#+sbcl sb-mop:class-direct-slots
#+clisp clos:class-direct-slots
#+mcl ccl:class-direct-slots
#+allegro ...
rg
Ron Garret wrote:
>
> Sure, but having to type foo:: all the time can get rather tedious,
> don't you think?
>
I guess I'll know when I get enough time to do CL.
I don't do CL on my day job. What little spare time I get goes in reading cll.
So with this post I am promising myself not to read cll for a month, instead do some coding.
My point was that at least personally the 'use...' stuff made a bigger impression
as if I *have to* do that to use a package. It is just that coming from 'normal' languages
(C/C++/Java) background, this can be confusing. The closest analogy in java might be
the 'static import' stuff they have now.
All the discussion about conflicts, shadowing etc etc can be scary. But once you know that
you can avoid that while using many libraries by not 'using' them :) it stops being scary.
I am just saying that this is one possibility for a newbee like me even though it
may not be the normal style in CL.
I just want to say this once more -
Your idiot guide to packages is fabulous.
I'd love to see one titled 'idiots guide to conditions'. Anyone ?
Rest of the CL stuff is covered pretty well in the available books (I think).
Some day I won't need any of that and will work off the CLHS.
-Antony
lisp linux <·········@lisp.linux> wrote:
+---------------
| I'd love to see one titled 'idiots guide to conditions'. Anyone ?
+---------------
Have you read these?
http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html
http://www.nhplace.com/kent/Papers/Exceptional-Situations-1990.htmlGo
http://www.nhplace.com/kent/Papers/Revision-18.txt
"Common Lisp Condition System, Revision #18"
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <································@comcast.com>,
lisp linux <·········@lisp.linux> wrote:
> I just want to say this once more -
> Your idiot guide to packages is fabulous.
Thanks!
rg
lisp linux <·········@lisp.linux> writes:
> My point was that at least personally the 'use...' stuff made a bigger
> impression as if I *have to* do that to use a package. It is just that
> coming from 'normal' languages (C/C++/Java) background, this can be
> confusing. The closest analogy in java might be the 'static import'
> stuff they have now. All the discussion about conflicts, shadowing
> etc etc can be scary.
Well, you get the same issue in Java with wild-carded import
statements. For example:
import java.util.*;
import java.sql.*;
If you then try to use Date as a class name, the compiler can't resolve
it unless you do the equivalent of a shadowing import by specifying one
of them as the imported one.
You also have the ability to get around things like that by using fully
qualified names, similar to the use of fully qualified symbols in Common
Lisp.
--
Thomas A. Russ, USC/Information Sciences Institute
On Mar 4, 11:57 am, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> lisp linux <·········@lisp.linux> writes:
> > My point was that at least personally the 'use...' stuff made a bigger
> > impression as if I *have to* do that to use a package. It is just that
> > coming from 'normal' languages (C/C++/Java) background, this can be
> > confusing. The closest analogy in java might be the 'static import'
> > stuff they have now. All the discussion about conflicts, shadowing
> > etc etc can be scary.
>
> Well, you get the same issue in Java with wild-carded import
> statements. For example:
>
> import java.util.*;
> import java.sql.*;
Ditto in C++. ``using namspace'' is similar to using a package (except
that namespaces work with bindings, not with the mapping of names to
symbol objects).
The using namespace directive creates a visibility window into the
current namespace, so that the lookup rules will recurse into that
namespace after searching the current one. It doesn't actually promote
the individual members of the used namespace into the current one.
However, the way it is designed, it's practically the same thing,
because there is no shadowing concept in C++ namespaces.
This makes the indiscriminate use of ``using namespace ...'' highly
braindamaged.
I don't write ``using namespace std;'' except in trivial, throwaway
programs. I always write separate using declarations which name every
identifier to be brought in from a foreign namespace. For all others,
I use fully qualified names.
If you use ``using namespace'', you open the door to future clashes.
When the contents of the namespace change, your program may then fail
to compile, even though nothing changed in your program. Simply, the
namespace acquired a new identifier which clashes with one of yours.
You then have to rename your identifier, or else eliminate the ``using
namespace'' by hunting down all of the identifier which are used from
that namespace and writing individual using declarations for them.
USE-PACKAGE is slightly less braindamaged in Lisp, because in the same
situation, you don't have to rename your identifier; you can shadow
it. This is still a maintenance nuisance, albeit a lesser one.
I was aware of all these issues before I came to Common Lisp, so the
potential problems with :USE in DEFPACKAGE were immediately clear.
There is a way to use this kind of mechanism in a non-braindamaged
way. You can create namespaces which are stable: that is to say, their
contents never change, once officially established. The purpose of
these namespaces it to capture the particular version of an API.
You have a main namespace which has everything in the current,
bleeding edge version of the library, and then versioned namespaces
which import specific identifiers. E.g. C++ syntax:
// full, current API
// write ``using namespace FooLib'' at your own risk!
namespace FooLib {
int blorch();
int wizzle();
int falberize();
}
// version 1 of the API:
namespace FooLib_1 {
using FooLib::blorch; // version 1 introduced blorch only
}
namespace FooLib_2 {
using namespace FooLib_1; // version 2 has all of version 1
using FooLib::wizzle; // additionally, wizzle was introduced
}
namespace FooLib_3 {
using FooLib::wizzle; // from version 2
using FooLib::falberize; // new
// note absence of blorch!
// it's an obsolete version 1 feature removed from version 3
// (blorch is now an inefficient backward compatibility hack
// for version 1 users; falberize offers the better way
// of blorching for those willing to update their code).
}
So now, the programmer can with confidence write:
using namespace FooLib_2;
knowing that the contents of FooLib_2 are precisely determined and
will never change. No matter what happens to FooLib, what new names
are introduced, upgrading FooLib will not introduce clashes to the
application which requests version 2.
You can do exactly the same thing with Lisp packages: write packages
whose only purpose is to import selected symbols from another package
and then re-export them. Then :USE FOOLIB-2 without worrying about
having to shadow anything in the future.
CL has had one revision of the ANSI standard only. If Common Lisp is
revised, what is going to happen to the "COMMON-LISP" package, I
wonder? Will (USE-PACKAGE "COMMON-LISP") bring in all the new
identifiers?
Or will its semantics be that it brings in just the CL sybols that
existed in the first standard? This would be a very good idea.
This issue should have been recognized in the first standard, which
should have defined a package nickname for the base package called
"CL-1994".
In article
<····································@u10g2000prn.googlegroups.com>,
Kaz Kylheku <········@gmail.com> wrote:
> If you use ``using namespace'', you open the door to future clashes.
> When the contents of the namespace change, your program may then fail
> to compile, even though nothing changed in your program. Simply, the
> namespace acquired a new identifier which clashes with one of yours.
This is only one of many ways in which changes to a library can cause
you grief. Functions and macros can change their APIs in ways that can
cause compilation failures without changing the list of exported
symbols. Worse, functions and macros can change in ways that don't
cause compilation failures, but rather introduce runtime errors. In
extreme cases, changes to a library can introduce transient errors. So
on the spectrum of things that can go wrong when things change, name
clashes are arguably among the least of your worries.
rg
From: Maciej Katafiasz
Subject: Re: Woohoo! My macros are now (semi) hygienic
Date:
Message-ID: <fpvl4r$fv4$3@news.net.uni-c.dk>
Den Mon, 25 Feb 2008 15:17:43 -0800 skrev Kaz Kylheku:
> Suppose foo has a member x that you access in the DO block, and bar
> doesn't have any member called x. So in that lexical scope, the name x
> refers to foo.x. Suppose that someone now edits the type definition of
> bar_record such that it acquires a member called x. Now when you
> recompile the WITH statement above, the expression x suddenly refers to
> bar.x! If bar.x is suitably typed, there will be no compiler error.
> Unintentional shadowing of a local variable can also take place: bad
> hygiene.
And that is different from (use-package :foo) how?
Cheers,
Maciej
On Feb 25, 4:05 pm, Maciej Katafiasz <········@gmail.com> wrote:
> Den Mon, 25 Feb 2008 15:17:43 -0800 skrev Kaz Kylheku:
>
> > Suppose foo has a member x that you access in the DO block, and bar
> > doesn't have any member called x. So in that lexical scope, the name x
> > refers to foo.x. Suppose that someone now edits the type definition of
> > bar_record such that it acquires a member called x. Now when you
> > recompile the WITH statement above, the expression x suddenly refers to
> > bar.x! If bar.x is suitably typed, there will be no compiler error.
> > Unintentional shadowing of a local variable can also take place: bad
> > hygiene.
>
> And that is different from (use-package :foo) how?
It's different in that USE-PACKAGE is required to detect conflicts,
which you have to explicitly deal with using SHADOW (resolve in favor
of local package) or UNINTERN (resolve in favor of library being
used).
But USE-PACKAGE (and the :USE interface of DEFPACKAGE) are
nevertheless blunt instruments.
What Ron is saying is that maintaining export lists by hand is some
kind of bug in packages that lexicons will fix for you. That's the
only the case if you are using both systems in a certain way.
If you care about precisely what is accessible where, you have to
maintain lists, no matter what namespace system you are using.
In the case of packages, you'd be maintaining import lists rather than
export lists. I.e. lists of symbols which are arguments to :IMPORT-
FROM or :SHADOWING-IMPORT-FROM in a DEFPACKAGE. (Since you can import
symbols which are not exported, exporting is somewhat immaterial,
except to the extent that it documents what is intended to be public
and affects whether you can use a single colon in qualified names).
In article
<····································@q78g2000hsh.googlegroups.com>,
Kaz Kylheku <········@gmail.com> wrote:
> On Feb 25, 4:05 pm, Maciej Katafiasz <········@gmail.com> wrote:
> > Den Mon, 25 Feb 2008 15:17:43 -0800 skrev Kaz Kylheku:
> >
> > > Suppose foo has a member x that you access in the DO block, and bar
> > > doesn't have any member called x. So in that lexical scope, the name x
> > > refers to foo.x. Suppose that someone now edits the type definition of
> > > bar_record such that it acquires a member called x. Now when you
> > > recompile the WITH statement above, the expression x suddenly refers to
> > > bar.x! If bar.x is suitably typed, there will be no compiler error.
> > > Unintentional shadowing of a local variable can also take place: bad
> > > hygiene.
> >
> > And that is different from (use-package :foo) how?
>
> It's different in that USE-PACKAGE is required to detect conflicts,
> which you have to explicitly deal with using SHADOW (resolve in favor
> of local package) or UNINTERN (resolve in favor of library being
> used).
The problem is that conflict-detection system for packages produces
false positives.
BTW, lexicons don't currently warn when existing bindings get shadowed
by new bindings, but there's no reason this feature couldn't be added if
people wanted it. It would be pretty easy to do.
> What Ron is saying is that maintaining export lists by hand is some
> kind of bug in packages that lexicons will fix for you.
One of several bugs that lexicons will fix (or, to put it more
diplomatically, one of several annoyances that lexicons will ameliorate).
> That's the
> only the case if you are using both systems in a certain way.
Of course. But that "certain way" is the most common way.
> If you care about precisely what is accessible where, you have to
> maintain lists, no matter what namespace system you are using.
No, you don't. Lexicons are really quite spiffy that way. You really
should take a look.
rg
Kaz Kylheku <········@gmail.com> wrote:
+---------------
| Maciej Katafiasz <········@gmail.com> wrote:
| > And that is different from (use-package :foo) how?
|
| It's different in that USE-PACKAGE is required to detect conflicts,
| which you have to explicitly deal with using SHADOW (resolve in favor
| of local package) or UNINTERN (resolve in favor of library being used).
+---------------
A third option [much less blunt than UNINTERN] is SHADOWING-IMPORT.
+---------------
| But USE-PACKAGE (and the :USE interface of DEFPACKAGE) are
| nevertheless blunt instruments.
+---------------
True, but often a handful of prior SHADOW or SHADOWING-IMPORT
operations can make USE-PACKAGE bearable.
And of course both :SHADOW and :SHADOWING-IMPORT clauses exist
in DEFPACKAGE, and their sequencing with the :USE clause is both
well-defined and useful:
http://alu.org/HyperSpec/Body/mac_defpackage.html
Macro DEFPACKAGE
...
The order in which the options appear in a DEFPACKAGE form is
irrelevant. The order in which they are executed is as follows:
1. :shadow and :shadowing-import-from.
2. :use.
3. :import-from and :intern.
4. :export.
SHADOWs are established first, since they might be necessary to
block spurious name conflicts when the :USE option is processed.
The :USE option is executed next so that :INTERN and :EXPORT
options can refer to normally inherited symbols. The :EXPORT
option is executed last so that it can refer to symbols created
by any of the other options; in particular, shadowing symbols
and imported symbols can be made external.
I have found that careful use of the :SHADOW and :SHADOWING-IMPORT
clauses can significantly improve the usability of the :USE clause.
+---------------
| If you care about precisely what is accessible where, you have to
| maintain lists, no matter what namespace system you are using.
|
| In the case of packages, you'd be maintaining import lists rather
| than export lists. I.e. lists of symbols which are arguments to
| :IMPORT-FROM or :SHADOWING-IMPORT-FROM in a DEFPACKAGE.
+---------------
Exactly. But depending upon the packages you want to inherit from, the
lists you will need of :SHADOW plus :SHADOWING-IMPORT-FROM symbols plus
packages :USE'd might (or might not) be a smaller maintainance burden
than the lists you's need for only :IMPORT-FROM or :SHADOWING-IMPORT-FROM
without any :USE.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Feb 27, 10:54 am, ····@rpw3.org (Rob Warnock) wrote:
> Kaz Kylheku <········@gmail.com> wrote:
> +---------------
> | Maciej Katafiasz <········@gmail.com> wrote:
> | > And that is different from (use-package :foo) how?
> |
> | It's different in that USE-PACKAGE is required to detect conflicts,
> | which you have to explicitly deal with using SHADOW (resolve in favor
> | of local package) or UNINTERN (resolve in favor of library being used).
> +---------------
>
> A third option [much less blunt than UNINTERN] is SHADOWING-IMPORT.
>
> +---------------
> | But USE-PACKAGE (and the :USE interface of DEFPACKAGE) are
> | nevertheless blunt instruments.
> +---------------
>
> True, but often a handful of prior SHADOW or SHADOWING-IMPORT
> operations can make USE-PACKAGE bearable.
>
> And of course both :SHADOW and :SHADOWING-IMPORT clauses exist
> in DEFPACKAGE, and their sequencing with the :USE clause is both
> well-defined and useful:
>
> http://alu.org/HyperSpec/Body/mac_defpackage.html
> Macro DEFPACKAGE
> ...
> The order in which the options appear in a DEFPACKAGE form is
> irrelevant. The order in which they are executed is as follows:
>
> 1. :shadow and :shadowing-import-from.
> 2. :use.
> 3. :import-from and :intern.
> 4. :export.
>
> SHADOWs are established first, since they might be necessary to
> block spurious name conflicts when the :USE option is processed.
> The :USE option is executed next so that :INTERN and :EXPORT
> options can refer to normally inherited symbols. The :EXPORT
> option is executed last so that it can refer to symbols created
> by any of the other options; in particular, shadowing symbols
> and imported symbols can be made external.
>
> I have found that careful use of the :SHADOW and :SHADOWING-IMPORT
> clauses can significantly improve the usability of the :USE clause.
>
> +---------------
> | If you care about precisely what is accessible where, you have to
> | maintain lists, no matter what namespace system you are using.
> |
> | In the case of packages, you'd be maintaining import lists rather
> | than export lists. I.e. lists of symbols which are arguments to
> | :IMPORT-FROM or :SHADOWING-IMPORT-FROM in a DEFPACKAGE.
> +---------------
>
> Exactly. But depending upon the packages you want to inherit from, the
> lists you will need of :SHADOW plus :SHADOWING-IMPORT-FROM symbols plus
> packages :USE'd might (or might not) be a smaller maintainance burden
> than the lists you's need for only :IMPORT-FROM or :SHADOWING-IMPORT-FROM
> without any :USE.
>
> -Rob
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
I also remember TFB's "conduit packages". They looked pretty neat to
me.
Cheers
--
Marco
On Feb 26, 1:17 am, Kaz Kylheku <········@gmail.com> wrote:
> On Feb 23, 8:50 am, Ron Garret <·········@flownet.com> wrote:
>
> >
>
> Automatically bringing together arbitrary symbols from different
> namespaces into one scope is braindamaged. Only in rare situations
> where the source namespace is very stable can you do a wholesale
> import of its bindings without naming the specific names that you
> want.
>
> It sounds like you're basically reinventing something which has the
> semantics of the Modula-2 WITH statement.
>
> VAR foo : foo_record, bar : bar_record;
>
> WITH foo DO
> WITH bar DO
> (* ... access members of bar and foo using short names ... *)
> END;
> END;
You are too young (and I am getting old :) ). That was already Pascal
(not Constanza :) ) before it was Modula-X.
Cheers
--
Marco
Marco Antoniotti <·······@gmail.com> wrote:
> You are too young (and I am getting old :) ). That was already Pascal
> (not Constanza :) )
Not even Costanza, BTW :-)
--
5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (0)1 53 14 59 22 ······@xemacs.org
On Feb 26, 12:07 pm, Didier Verna <······@lrde.epita.fr> wrote:
> Marco Antoniotti <·······@gmail.com> wrote:
> > You are too young (and I am getting old :) ). That was already Pascal
> > (not Constanza :) )
>
> Not even Costanza, BTW :-)
Now! I am the italian here and I cannot even spell an italian name.
Too much CLL I guess :)
Cheers
marco
Marco Antoniotti <·······@gmail.com> writes:
> On Feb 26, 12:07�pm, Didier Verna <······@lrde.epita.fr> wrote:
>> Marco Antoniotti <·······@gmail.com> wrote:
>> > You are too young (and I am getting old :) ). �That was already Pascal
>> > (not Constanza :) )
>>
>> � Not even Costanza, BTW :-)
>
> Now! I am the italian here and I cannot even spell an italian name.
But ... he's German! :-)
> Too much CLL I guess :)
>
> Cheers
>
> marco
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Feb 26, 6:02 pm, Duane Rettig <·····@franz.com> wrote:
> Marco Antoniotti <·······@gmail.com> writes:
> > On Feb 26, 12:07 pm, Didier Verna <······@lrde.epita.fr> wrote:
> >> Marco Antoniotti <·······@gmail.com> wrote:
> >> > You are too young (and I am getting old :) ). That was already Pascal
> >> > (not Constanza :) )
>
> >> Not even Costanza, BTW :-)
>
> > Now! I am the italian here and I cannot even spell an italian name.
>
> But ... he's German! :-)
Yep. But the name "Costanza" looks pretty italian to me :) At least
he never appeared in a "Seinfeld" episode :)
Cheers
Marco
Marco Antoniotti <·······@gmail.com> writes:
> On Feb 26, 6:02�pm, Duane Rettig <·····@franz.com> wrote:
>> Marco Antoniotti <·······@gmail.com> writes:
>> > On Feb 26, 12:07�pm, Didier Verna <······@lrde.epita.fr> wrote:
>> >> Marco Antoniotti <·······@gmail.com> wrote:
>> >> > You are too young (and I am getting old :) ). �That was already Pascal
>> >> > (not Constanza :) )
>>
>> >> � Not even Costanza, BTW :-)
>>
>> > Now! �I am the italian here and I cannot even spell an italian name.
>>
>> But ... he's German! � :-)
>
> Yep. But the name "Costanza" looks pretty italian to me :)
Of course. But ...
> At least he never appeared in a "Seinfeld" episode :)
But ... _he_'s Jewish! (well, ok, at least half)
Perhaps we've finally found the truly universal name?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Marco Antoniotti <·······@gmail.com> writes:
>
>> On Feb 26, 12:07 pm, Didier Verna <······@lrde.epita.fr> wrote:
>>> Marco Antoniotti <·······@gmail.com> wrote:
>>>> You are too young (and I am getting old :) ). That was already Pascal
>>>> (not Constanza :) )
>>> Not even Costanza, BTW :-)
>> Now! I am the italian here and I cannot even spell an italian name.
>
> But ... he's German! :-)
I'm European. ;) Yes, I'm German and my last name is Italian. But the
misspelling "Constanza" is extremely common.
Compare http://www.pascalcostanza.de to http://www.pascalconstanza.de/ ;)
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
>
> I'm European. ;) Yes, I'm German and my last name is Italian. But the
> misspelling "Constanza" is extremely common.
>
Well, when people are intending to write your name of course it's a
misspelling, but "Constanza" with 2 "n"s is also a name (though
typically a female first or middle name) used mostly in parts of Spain
and South America.