ELS'18 - 11th European Lisp Symposium
Centro Cultural Cortijo de Miraflores
Marbella, Málaga
Spain
April 16-17 2018
Sponsored by Brunner Software GmbH and EPITA
http://www.european-lisp-symposium.org/
*** Important: submission deadline extended to Sunday Feb. 25!
The purpose of the European Lisp Symposium is to provide a forum for
the discussion and dissemination of all aspects of design,
implementation and application of any of the Lisp and Lisp-inspired
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP,
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We
encourage everyone interested in Lisp to participate.
The 11th European Lisp Symposium invites high quality papers about
novel research results, insights and lessons learned from practical
applications and educational perspectives. We also encourage
submissions about known ideas as long as they are presented in a new
setting and/or in a highly elegant way.
Topics include but are not limited to:
- Context-, aspect-, domain-oriented and generative programming
- Macro-, reflective-, meta- and/or rule-based development approaches
- Language design and implementation
- Language integration, inter-operation and deployment
- Development methodologies, support and environments
- Educational approaches and perspectives
- Experience reports and case studies
We invite submissions in the following forms:
Papers: Technical papers of up to 8 pages that describe original
results or explain known ideas in new and elegant ways.
Demonstrations: Abstracts of up to 2 pages for demonstrations of
tools, libraries, and applications.
Tutorials: Abstracts of up to 4 pages for in-depth presentations
about topics of special interest for at least 90 minutes and up to
180 minutes.
The symposium will also provide slots for lightning talks, to be
registered on-site every day.
All submissions should be formatted following the ACM SIGS guidelines
and include ACM Computing Classification System 2012 concepts and
terms. Submissions should be uploaded to Easy Chair, at the following
address: https://www.easychair.org/conferences/?conf=els2018
Note: to help us with the review process please indicate the type of
submission by entering either "paper", "demo", or "tutorial" in the
Keywords field.
Important dates:
- 25 Feb 2018 Submission deadline (*** extended! ***)
- 19 Mar 2018 Notification of acceptance
- 25 Mar 2018 Early registration deadline
- 02 Apr 2018 Final papers due
- 16-17 Apr 2018 Symposium
Programme chair:
David Cooper, Genworks Intl., USA
Local chairs:
Andrew Lawson, Ravenpack, Spain
Programme committee:
Andy Wingo, Igalia, Spain
Christophe Rhodes, Goldsmiths University, UK
Christopher Wellons Null Program Canada
Irène Durand, LaBRI, Université de Bordeaux, France
Julian Padget, University of Bath, UK
Ludovic Courtès, Inria, France
Michael Sperber, DeinProgramm, Germany
Nicolas Neuss, FAU Erlangen-Nürnberg, Germany
Olin Shivers Northwestern University USA
Philipp Marek, Austria
Robert Strandh, LaBRI, Université de Bordeaux, France
Sacha Chua Living an Awesome Life Canada
Scott McKay, Future Fuel, USA
Search Keywords:
#els2018, ELS 2018, ELS '18, European Lisp Symposium 2018,
European Lisp Symposium '18, 10th ELS, 10th European Lisp Symposium,
European Lisp Conference 2018, European Lisp Conference '18
--
Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
Reminder: submission deadline this sunday!
ELS'18 - 11th European Lisp Symposium
Centro Cultural Cortijo de Miraflores
Marbella, Málaga
Spain
April 16-17 2018
Sponsored by Brunner Software GmbH and EPITA
http://www.european-lisp-symposium.org/
The purpose of the European Lisp Symposium is to provide a forum for
the discussion and dissemination of all aspects of design,
implementation and application of any of the Lisp and Lisp-inspired
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP,
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We
encourage everyone interested in Lisp to participate.
The 11th European Lisp Symposium invites high quality papers about
novel research results, insights and lessons learned from practical
applications and educational perspectives. We also encourage
submissions about known ideas as long as they are presented in a new
setting and/or in a highly elegant way.
Topics include but are not limited to:
- Context-, aspect-, domain-oriented and generative programming
- Macro-, reflective-, meta- and/or rule-based development approaches
- Language design and implementation
- Language integration, inter-operation and deployment
- Development methodologies, support and environments
- Educational approaches and perspectives
- Experience reports and case studies
We invite submissions in the following forms:
Papers: Technical papers of up to 8 pages that describe original
results or explain known ideas in new and elegant ways.
Demonstrations: Abstracts of up to 2 pages for demonstrations of
tools, libraries, and applications.
Tutorials: Abstracts of up to 4 pages for in-depth presentations
about topics of special interest for at least 90 minutes and up to
180 minutes.
The symposium will also provide slots for lightning talks, to be
registered on-site every day.
All submissions should be formatted following the ACM SIGS guidelines
and include ACM Computing Classification System 2012 concepts and
terms. Submissions should be uploaded to Easy Chair, at the following
address: https://www.easychair.org/conferences/?conf=els2018
Note: to help us with the review process please indicate the type of
submission by entering either "paper", "demo", or "tutorial" in the
Keywords field.
Important dates:
- 18 Feb 2018 Submission deadline
- 19 Mar 2018 Notification of acceptance
- 25 Mar 2018 Early registration deadline
- 02 Apr 2018 Final papers due
- 16-17 Apr 2018 Symposium
Programme chair:
David Cooper, Genworks Intl., USA
Local chairs:
Andrew Lawson, Ravenpack, Spain
Programme committee:
Christophe Rhodes, Goldsmiths University, UK
Christopher Wellons Null Program Canada
Irène Durand, LaBRI, Université de Bordeaux, France
Julian Padget, University of Bath, UK
Ludovic Courtès, Inria, France
Michael Sperber, DeinProgramm, Germany
Nicolas Neuss, Universität Karlsruhe, Germany
Olin Shivers Northwestern University USA
Robert Strandh, LaBRI, Université de Bordeaux, France
Sacha Chua Living an Awesome Life Canada
Scott McKay, Future Fuel, USA
Search Keywords:
#els2018, ELS 2018, ELS '18, European Lisp Symposium 2018,
European Lisp Symposium '18, 10th ELS, 10th European Lisp Symposium,
European Lisp Conference 2018, European Lisp Conference '18
--
Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
Hi,
In the CLHS page for ENSURE-GENERIC-FUNCTION, there is this paragraph:
"If function-name specifies a generic function that has a different
value for the :generic-function-class argument and if the new generic
function class is compatible[1] with the old, change-class is called to
change the class of the generic function; otherwise an error is
signaled."
In the AMOP however, one can read the following.
>From the page on ENSURE-GENERIC-FUNCTION:
"The behavior of this function is actually implemented by the generic
function ensure-generic-function-using-class. When
ensure-generic-function is called, it immediately calls
ensure-generic-function-using-class and returns that result as its own."
And then from the page on ENSURE-GENERIC-FUNCTION-USING-CLASS:
"If the class of the generic-function-or-nil argument is not the same as
the class specified by the :generic-function-class argument, an error is
signaled."
Let alone the fact that this should only apply when there actually is an
existing generic function, this seems to be in contradiction with the
Common Lisp standard, as it would explicitly forbid changing the class
of the generic function, even in a "compatible" way.
Comments?
Footnotes:
[1] BTW, what does "compatible" mean ?
--
Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
Hello,
there is something annoying with
ensure-generic-function-using-class. The MOP specifies that if the
:generic-function-class option is not provided, it defaults to
standard-generic-function. While this makes perfect sense when the
generic function doesn't already exist, it seems to also apply when it
does.
As a result, if you want to call ensure-generic-function on an existing
generic function using a different meta-class, for instance like this:
(ensure-generic-function gf-name :generic-function-class (class-of gf))
This is a bit annoying, and I don't understand the rationale behind
this, if there's one. Why not defaulting to the existing generic
function's meta-class?
--
Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
OK, I'm setting the day and time for the next ASDF debugging session
to Tuesday January 2nd 2018 at 14:00 EST (19:00 UTC). Please send me a
private email if you can make it, I'll add you to a Google Calendar
event with a Hangout invitation.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
When it comes to giving, some men stop at nothing. — Saul Gorn
On Wed, Dec 27, 2017 at 6:06 PM, Faré <fahree(a)gmail.com> wrote:
> On Wed, Dec 27, 2017 at 10:33 AM, Robert Goldman <rpgoldman(a)sift.info> wrote:
>> On 4 Dec 2017, at 21:56, Faré wrote:
>>> https://bugs.launchpad.net/asdf/+bug/1739514
>>> Basically, ASDF fails spuriously rebuilds misnamed secondary systems
>>> and/or things that depend on them, instead of just issuing a warning
>>> as intended.
>>
>> Another editing query here. Looks like it might be either "ASDF fails to rebuild" or "ASDF spuriously rebuilds misnamed..."
>>
> Yes, it's "ASDF spuriously rebuilds misnamed...".
>
> Note that if it were a simple circular dependency, it would have just
> broken the build and be very visible and I'd have caught it last year.
>
> Without having looked at the code or tried to debug it yet, my working
> hypothesis is that having "foo" in "foo.asd" depend on "bar" also
> defined in "foo.asd" causes dependency from (define-op "foo") to
> (define-op . "bar"), which is always in need of build because there is
> no "bar.asd" and the associated timestamp is therefore NIL. If that is
> correct, the backward-compatible solution would be to make sure that
> "bar" remembers that it was defined in "foo.asd", so that it gets the
> timestamp from "foo.asd", and the next time around, if there is no
> up-to-date "bar.asd", ASDF falls back on looking at the previously
> loaded "foo.asd" or a more up-to-date version of it.
>
> Note that if "bar" is defined in both "foo.asd" and "bar.asd" you'll
> still have a mighty bug. Therefore people should still fix their code
> to properly name secondary system, ASDF should still issue a warning
> when they are misnamed, and this warning should still be upgraded to a
> cerror then an error when all of Quicklisp is fixed (>300 systems).
Dear CLers,
with ASDF 3.3.1 released and the syntax-control branch pending review,
there's not much left for me to do with ASDF before I actually retire.
Now I'm looking for hackers to whom to pass the torch of ASDF hacking.
It so happens that I seem to have introduced (probably with 3.3.0) a
regression that breaks static image dumping of workout-timer with
cffi-toolchain. If people are interested, I could do the entire
debugging session over Google Hangouts, from isolating the bug and
filing a bug report to writing regression test and submitting a merge
request. That would be a good way to introduce newcomers to ASDF
hacking. Having a public ask questions as I make progress would be a
good way to keep the video relevant. Is anyone interested?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
If there's a book you really want to read but it hasn't been written yet,
then you must write it. — Toni Morrison [same with software, —♯f]
Hi,
Computing an effective method depends on the generic function's method
combination. But is it also the case for computing the discriminating
function?
I don't see why it should in theory, but evidence seems to suggest
otherwise[1]. Maybe it does for technical reasons?
Thanks.
Footnotes:
[1] In SBCL for instance, flushing the effective method cache is not
enough for direct modifications to a generic function's method
combination to take effect on the next call.
--
Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
I noticed a mistake in one of the examples in the hyperspec, and went
looking for an errata. I saw this page on cliki but didn't find the
issue there, so I am wondering if the "comprehensive" list is
elsewhere:
http://www.cliki.net/Proposed%20ANSI%20Revisions%20and%20Clarifications
FWIW, the issue is in the second example under the documentation for SHADOW[1].
(package-shadowing-symbols (make-package 'temp)) => NIL
(find-symbol 'car 'temp) => CAR, :INHERITED
FIND-SYMBOL does not accept a symbol as the first argument. All the
Lisps that I have checked this on signal an error.
Also, I think the first example should be modified to:
(package-shadowing-symbols (make-package 'temp :use '("CL")))
SBCL by default does not use the CL package. So (find-symbol "CAR"
'temp) returns NIL, NIL instead. It took me a while to figure why the
spec example returned a different set of values.
Chaitanya
1. http://www.lispworks.com/documentation/HyperSpec/Body/f_shadow.htm
Well, that's a great idea!
Il 19 dic 2017 11:36, "David McClain" <dbm(a)refined-audiometrics.com> ha
scritto:
It seems to me that, instead of performing totally useless computations for
POW, a group like CERN might enlist the miners to search for W-Boson events
from their detector trails, or astronomers might enlist the mining enclaves
to search for SETI events… (no joke…)
- DM
On Dec 18, 2017, at 23:03, Antoniotti Marco <antoniotti.marco@disco.
unimib.it> wrote:
On Dec 18, 2017, at 23:54 , Pascal Bourguignon <pjb(a)informatimago.com>
wrote:
On 18 Dec 2017, at 23:31, David McClain <dbm(a)refined-audiometrics.com>
wrote:
umm… was this supposed to be some kind of joke? I’ll bite... I don’t get
it. I was actually hoping to learn something here...
But the code does look rather peculiar on close inspection. Why the use of
macros for pushing new transaction blocks? And the conversions to octet
vectors may work for strings, but not in general for arbitrary integer or
float values…
If it is supposed to be a joke, I’ll chuckle and just chuck the code…
I guess not: https://dev.to/damcosset/trying-to-understand-
blockchain-by-making-one-ce4
It’s like, everybody will be busy implementing blockchains. It’s the new
fizz-buzz…
… or planting tulips :) :) :)
Cheers
MA
--
Marco Antoniotti