Antoniotti Marco | 4 Feb 19:03 2016
Picon

Naming suggestions

Dear all,

in the quest for RESTHBDB) RE-doing Stuff That Has Been Done Before) I am trying to come up with a name for a referencing/dereferencing operator.

Think of something like

(<name-of-reference-operator> #2A((1 0) (0 1)) 0 0) ==> 1

of

(<name-of-reference-operator> #H((foo . bar) (we . 42)) ‘foo) ==> BAR ; I am cheating.   #H(..) is a hash table.

SETF methods will be defined as expected.

Now.  What could be a good name?  I have the following list.

REF
REF$
[]
[[]]
AT
<at>
GETAT

What do you think? (Full disclosure: I usually refrain from taking up non alphabetic names)

Cheers

MA

--
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please check: http://cdac.lakecomoschool.org

Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me first.





Didier Verna | 21 Jan 10:38 2016
Face
Picon
Picon
Picon
Picon
Gravatar

[CfP] 9th European Lisp Symposium, May 9-10, Krakow, Poland


		 ELS'16 - 9th European Lisp Symposium

		    Department of Computer Science
	       AGH University of Science and Technology
			    Kraków, Poland

			    May 9-10, 2016

		   In cooperation with: ACM SIGPLAN

 Sponsored by EPITA, Franz Inc., LispWorks Ltd. and Dept. of Computer
			   Science AGH UST

	       http://www.european-lisp-symposium.org/

Recent news:

- Submission deadline in less than a month!
- 3nd invited speaker announced: Stephan Karpinski on Julia: to Lisp
  or Not to Lisp?

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 9th 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 classification categories and terms. For more
information on the submission guidelines and the ACM keywords, see:
http://www.acm.org/sigs/publications/proceedings-templates and
http://www.acm.org/about/class/1998. The conference proceedings will be
published in the ACM Digital Library.

Important dates:

 -   19 Feb 2016 Submission deadline
 -   25 Mar 2016 Notification of acceptance
 -   15 Apr 2016 Early registration deadline
 -   22 Apr 2016 Final papers due
 - 9-10 May 2016 Symposium

Programme chair:
  Irène Durand, LaBRI, University of Bordeaux, France

Local chair:
  Michał Psota, Emergent Network Defense, Kraków, Poland

Programme committee:
  Antonio Leitao — INESC-ID / Instituto Superior Técnico, Universidade
    de Lisboa, Portugal
  Charlotte Heerzel — IMEC, Leuven, Belgium
  Christian Queinnec — University Pierre et Marie Curie, Paris 6, France
  Christophe Rhodes — Goldsmiths, University of London, United Kingdom
  Didier Verna  — EPITA Research and Development Laboratory, France
  Erick Gallesio — University of Nice-Sophia Antipolis, France
  François-René Rideau, Google, USA
  Giuseppe Attardi — University of Pisa, Italy
  Henry Lieberman — MIT, USA
  Kent Pitman, HyperMeta Inc., USA
  Leonie Dreschler-Fischer — University of Hamburg, Germany
  Pascal Costanza — Intel Corporation, Belgium
  Robert Strandh — University of Bordeaux, France

Search Keywords:

#els2016, ELS 2016, ELS '16, European Lisp Symposium 2016,
European Lisp Symposium '16, 9th ELS, 9th European Lisp Symposium,
European Lisp Conference 2016, European Lisp Conference '16

--

-- 
 <at> -quartet live: Sunset/Sunside, Paris, Jan 26 2016 !
Book now: http://www.sunset-sunside.com/2016/1/artiste/2101/3453/

Lisp, Jazz, Aïkido: http://www.didierverna.info

Alessio Stalla | 30 Dec 00:52 2015
Picon

Package extensions usage

Hi everyone,

I'd like to run a little poll among experienced Lisp developers. The topic is the usage in the wild of the extensions to the package system provided by various implementations. My apologies to people who are subscribed to the ABCL mailing list, where some time ago I submitted the same questions getting back several insightful answers but no actual data.

So, here is how it is. I'm working on a novel idea (I hope) regarding symbols and packages; I won't go into the details now. It suffices to say that there is some overlap with features offered by certain Lisp implementations, namely:

 * package-local nicknames: the ability to specify, for each package, a list of nicknames for other packages which are in effect only in that package; available on ABCL and SBCL (http://www.sbcl.org/manual/#Package_002dLocal-Nicknames) and possibly other implementations I'm not aware of.
 * "Hierarchical" packages: a naming convention for packages understood by the reader and a few support functions, which allow to have concise nicknames for a group of closely related packages, such as com.foo.mylib.api and com.foo.mylib.implementation. Found natively in Allegro CL (http://franz.com/support/documentation/current/doc/packages.htm) and in an open-source library by P. Bourguignon.

My questions:
1) First and foremost, is anybody actually using those features? What are you using them for?
2) If yes, how useful are they for you? What shortcomings do you find in them?
Didier Verna | 7 Oct 18:10 2015
Face
Picon
Picon
Picon
Picon
Gravatar

[CfP] European Lisp Symposium 2016, May 9-10, Kraków, Poland


		 ELS'16 - 9th European Lisp Symposium
	       AGH University of Science and Technology
			    Kraków, Poland

			    May 9-10, 2016

	       http://www.european-lisp-symposium.org/

		Sponsored by EPITA and AGH University

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 9th 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 classification categories and terms. For more
information on the submission guidelines and the ACM keywords, see:
http://www.acm.org/sigs/publications/proceedings-templates and
http://www.acm.org/about/class/1998.

Important dates:

 -   19 Feb 2016 Submission deadline
 -   25 Mar 2016 Notification of acceptance
 -   15 Apr 2016 Early registration deadline
 -   22 Apr 2016 Final papers due
 - 9-10 May 2016 Symposium

Programme chair:
  Irène Durand, University of Bordeaux, France

Local chair:
  Michał Psota, Emergent Network Defense, Kraków, Poland

Programme committee:
  Antonio Leitao — INESC-ID / Instituto Superior Técnico, Universidade
    de Lisboa, Portugal
  Charlotte Heerzel — IMEC, Leuven, Belgium
  Christian Queinnec — University Pierre et Marie Curie, Paris 6, France
  Christophe Rhodes — Goldsmiths, University of London, United Kingdom
  Didier Verna  — EPITA Research and Development Laboratory, France
  Erick Gallesio — University of Nice-Sophia Antipolis, France
  Francois-René Rideau, Google, USA
  Giuseppe Attardi — University of Pisa, Italy
  Henry Lieberman — MIT, USA
  Kent Pitman, HyperMeta Inc., U.S.A.
  Leonie Dreschler-Fischer — University of Hamburg, Germany
  Pascal Costanza — Intel Corporation, Belgium
  Robert Strandh — University of Bordeaux, France

Search Keywords:

#els2016, ELS 2016, ELS '16, European Lisp Symposium 2016,
European Lisp Symposium '16, 9th ELS, 9th European Lisp Symposium,
European Lisp Conference 2016, European Lisp Conference '16

--

-- 
My new Jazz CD entitled "Roots and Leaves" is out!
Check it out: http://didierverna.com/records/roots-and-leaves.php

Lisp, Jazz, Aïkido: http://www.didierverna.info

Edi Weitz | 4 Sep 11:43 2015
Picon

Conditions and *PRINT-READABLY*

Hi everybody!

With the code at the end of this mail I would have expected an outcome
similar to this one

  R: T  , E: T   - [REFUSED TO PRINT]
  R: T  , E: NIL - [REFUSED TO PRINT]
  R: NIL, E: T   - #<MY-CONDITION 20098B07>
  R: NIL, E: NIL - My condition occured.

because the standard says that "if *PRINT-READABLY* is true, printing
proceeds as if *PRINT-ESCAPE* were also true."  This would mean that
the first two lines should look the same because the value of
*PRINT-ESCAPE* is irrelevant in this case.  However, while this is
what happens for example with LispWorks, AllegroCL, and CLISP, in some
other Lisps like SBCL, CCL, and ECL the second line looks like the
fourth.

Isn't that wrong?  Or is their interpretation of the standard that the
report function is responsible for obeying *PRINT-READABLY*?  But how
does that fit with the possibility of using strings for :REPORT?

Thanks,
Edi.

(define-condition my-condition ()
  ()
  (:report "My condition occured."))

(defun test ()
  (let ((error (make-condition 'my-condition)))
    (dolist (readably '(t nil))
      (dolist (escape '(t nil))
        (format t "~&R: ~3A, E: ~3A - " readably escape)
        (handler-case
            (write error :readably readably :escape escape)
          (print-not-readable ()
            (write-string "[REFUSED TO PRINT]")))))))

Edi Weitz | 29 Aug 11:10 2015
Picon

PRINT-OBJECT for built-in classes

The following "works" in three different CL implementations I tried
while in three others the way complex numbers are printed doesn't
change.

? (defmethod print-object ((obj complex) stream)
     (format stream "#< ~A + ~A * I >"
                (realpart obj) (imagpart obj)))
#<STANDARD-METHOD PRINT-OBJECT (COMPLEX T)>
? #c(1 1)
#< 1 + 1 * I >

My understanding of 22.1.2 of the standard is that each Lisp MUST have
a PRINT-OBJECT method for complex numbers.  The question then is
whether I'm allowed to redefine it like above (I think I am) and/or
whether an implementation is allowed to accept this redefinition
without a warning but then to ignore it (which, as I said, is what
happens in three respectable Lisps).

Thanks,
Edi.

[Note: There's no point in talking me out of this as I don't actually
want to do it anyway.  It's just an example and I'm only interested in
what exactly is governed by the standard.  Complex numbers are also
just an example.  I'm interested in PRINT-OBJECT for built-in classes
in general.]

Jean-Claude Beaudoin | 3 Aug 23:27 2015
Picon

Proper behavior of slot-initforms in defstruct?


Please consider the following code:

(defparameter init-a 1)

(let ((init-a 42) (serial-no 0))
  (defstruct foo (a init-a) (b (incf serial-no)))
  (defun get-foo-serial-no () serial-no))

(defstruct (bar (:include foo)) (c 33) d)

When one loads the above and then try to call #'make-bar the result
varies widely from one lisp implementation (clisp) to another.

clisp: (make-bar) --> #S(BAR :A 1 :B 1 :C 33 :D NIL)
ccl: (make-bar) --> <enter the debugger saying: "Unbound variable: SERIAL-NO">

lispworks, allegro and sbcl also behave more or less like ccl.

What is the proper ANSI-CL behavior in this case here?
Is clisp right in evaluating the slot initform in its "proper" lexical context?
Or is the correct behavior to replicate the slot initform verbatim
in the sub-structure constructor regardless of its original lexical context
like the others do?

I guess that this question has probably been asked before, in a somewhat
distant past, but my google skills have not been sharp enough to find it, sorry.


shenanigans | 3 Aug 17:12 2015
Picon

Erlang style processes in Common Lisp

Creators of Erlang have a Lisp background, and one feature of the Erlang 
VM (BEAM) that I'd like back-ported into Common Lisp is their process.

An Erlang "process" is cheap to create, cheap to destroy, cheap when 
blocked, and upon exit performs bulk gc of its allocated memory; e.g., 
munmap().

Handling tens of thousands of requests per second per node isn't 
uncommon, and these often have *several* workers per request or 
connection: hundreds of thousands of processes.  Under such scenarios, 
anything less than this approach to lightweight processes might suffer 
from stalls during long gc runs that would be avoided or significantly 
reduced under Erlang's model.

How might we get equivalent cheap ephemeral processes into a 
contemporary Common Lisp implementation?

For those unfamiliar with it, what Erlang means by "process" stems from 
an implementation of Actor Model with caveats.  Each process is more 
co-routine than thread, and many may run within the same OS thread 
managed by the Erlang scheduler.  The BEAM VM pre-empts processes via 
"reduction" counting, which may be understood as unit of VM time.  Their 
famed tag line, "Let it crash," may be loosely understood in CL terms as 
an implicit HANDLER-CASE.

The open question here is to address a stated non-goal of CL-MUPROC, "we 
rely on the CL implementation's MP system" and "considerably heavier 
than Erlang processes".  [See presentation link from 
https://common-lisp.net/project/cl-muproc/ ]

Some Erlang-on-CL packages use OS threads or in the case of 
Erlang-in-Lisp, fork().  While easier for a library author to implement, 
these contradict the definition of cheap here.  Other such packages punt 
the issue altogether and instead focus only on pattern-matching aspects 
of Erlang the language.

Then there's Lisp-Flavoured-Erlang, and Elixir offers hygienic macros 
that manipulate the full AST properly-- all play nice on same Erlang VM 
at runtime-- for people simply looking to avoid Erlang syntax or 
semantics.  But let's focus on cheap Erlang style processes in Common 
Lisp here, please.

1. Semantics of library elements are straight-forward enough (e.g., 
SPAWN, EXIT) and may be borrowed wholesale and safely named within their 
own package.

2. Memory allocation & garbage collection:

Erlang BEAM VM doesn't begin to reclaim memory until very late, so an 
initial implementation here might assume ephemeral worker processes and 
omit gc until exit of a worker.  However, some processes are long-lived 
in practice.

One compromise might be acceptable: one nursery per process, but 
anything promoted to higher generations gets handled however your gc 
does it now.

This states nothing about use of shared versus multiple heaps across OS 
threads, so such matters may continue to be implementation-dependent.

3. Co-routines:

For something similar to Erlang's reductions, there would need to be a 
measure of runtime complexity per process.

However, I've used single thread co-routines for near realtime systems 
in C and CL with a loop of function pointers and ensuring that each 
referenced function executes under some threshold determined through 
experimentation and confirmed via test cases.  No pre-empting needed.  
While fragile and not easily portable across different hardware 
(including same architecture), this may be acceptable for a preliminary 
draft.

Using CL-MUPROC routines as an example and extending MUPROCN: perhaps 
its body becomes this top-level list of functions from which 
interleaving across processes may occur. Then add variations for playing 
well with DO or LOOP semantics.

4. Message-passing:

SBCL's sb-concurrency extension with Queue and Mailbox (implementation 
of "Optimistic FIFO Queue") can be the solution here too.  More aligned 
with CL principles, allowing for multiple mailboxes-- and therefore 
priority messaging-- would be a welcome advancement beyond Erlang.  
(Erlang allows only one mailbox per process: sequential but with pattern 
matching, nothing out-of-band...)

An important implementation detail that simplifies gc and increases 
cache locality across NUMA nodes: messages get duplicated when 
delivered-- each process only references its own copy!

5. (Almost) nothing shared:

Erlang enforces strict prohibition against shared memory, and common 
practice is to use an in-memory database (ETS) as key/value store in 
lieu of globals.  Scala allows but discourages shared memory.

A CL-inspired take on this might be to use SBCL's approach with thread 
creation: upon creating a new process, you get: A) global special 
values, but modify at own risk... B) LET bindings are local to each 
process; C) threads don't inherit dynamic bindings from parent.  i.e., 
http://sbcl.org/manual/index.html#Special-Variables

6. Scheduling processes on OS threads:

This is delicate in Erlang, and I've experienced specialized use cases 
interfering with their scheduler when under heavy load. Instead for our 
purposes, let the programmer handle the mapping of processes to OS 
threads.  Less is more here.

7. Finally, gen_server & OTP fiends may be implemented as their own 
packages... or skipped entirely!

Thoughts on feasibility?

Thanks,
-Daniel

Edi Weitz | 21 Jul 09:46 2015
Picon

Caching of effective methods in custom method combinations

Hi everybody,

Here's some behavior I see on SBCL as well as LispWorks, so I'm
assuming for now they're right in doing so.  My question would be why
they are.

I start with the following code which I compile and load:

  ;;;;;;;;;;;;;;;;;;;;;;;;

  (defvar *current-qualifiers* '(:a :b :c))

  (define-method-combination test ()
      ((methods *))
    (let ((selected-methods (loop for method in methods
                                  when (intersection (method-qualifiers method)
                                                     *current-qualifiers*)
                                    collect method)))
      `(call-method ,(first selected-methods)
                    ,(rest selected-methods))))

  (defgeneric foo (thing)
    (:method-combination test))
  (defmethod foo :a (thing)
    '(:red))
  (defmethod foo :b (thing)
    '(:blue))

  ;;;;;;;;;;;;;;;;;;;;;;;;;;

Now, in the REPL I do the following:

  CL-USER> (foo 42)
  (:BLUE)
  CL-USER> (setq *current-qualifiers* '(:a :c))
  (:A :C)
  CL-USER> (foo 42)
  (:BLUE)

I almost expected this.  The effective method obviously isn't computed
anew but was cached.  But even if I now re-evaluate the
DEFINE-METHOD-COMBINATION form, (FOO 42) will still return (:BLUE).
Only if I re-evaluate the DEFGENERIC form will the return value change
to (:RED).

My question is if the standard somewhere allows this caching to
happen.  That would for example mean that any kind of "dynamic method
combination" (for example based on the time of the day, just for
grins) is impossible.

Or am I missing something and my interpretation is wrong?

Thanks,
Edi.

Elias Mårtenson | 4 Jul 13:30 2015
Picon

Should GC hooks be used to help broken software?

The following question was raised during my development of an asynchronous library I'm currently building for RabbitMQ.

In summary, the library allows you to create an object of type ASYNCH-CONNECTION, from which instances of ASYNC-CHANNEL can be retrieved. A connection holds a reference to all channels that it uses, and each channel holds a reference to its connection. The connection object has a pointer to a native CFFI object that for the underlying connection (my library is built on the RabbitMQ C API).

My question is: Should I use trivial-garbage to create a GC hook for the connection object so that if the user of the library forgets to close the connection, it will get closed eventually once it's GC'ed?

I can see arguments for both behaviours:
  • It's a bad idea, since losing the reference to the connection object means that the program is broken, and silently cleaning up the underlying connection might hide the fact there is a bug (if the GC doesn't run often enough I might have hundreds or even thousands of lingering connections)
  • On the other hand, it might be a good idea since Lisp developers often use the REPL to experiment, so it's easy to accidentally lose a reference to an object during testing. Thus, using the GC hook will improve the stability of one's development environment.
To me, there is no strictly correct answer to the question, which is why I'm asking for suggestions from you guys.

Regards,
Elias (loke on #lisp)
Edi Weitz | 3 Jul 09:09 2015
Picon

Do symbols need to be EQ?

Just out of curiosity and without any relevance in practise:

Is there one place in the standard where it is explicitly said that
two symbols which are the "same" symbol must be "identical"?  I know
that there are a couple of examples where this is implied, but
formally the examples aren't part of the standard, right?

The EQ dictionary entry for example shows this example:

  (eq 'a 'a)  =>  true

and then it continues with this note (emphasis mine): "Symbols that
print the same USUALLY are EQ to each other because of the use of the
INTERN function."

And the entry for INTERN is actually the closest I could find in terms
of clarification because it says that if a symbol of a specified name
is already accessible, _IT_ is returned -- which sounds like object
identity to me.

But how does this fit into the picture?

  CL-USER 1 > (defparameter *s* 'foo)
  *S*
  CL-USER 2 > (unintern 'foo)
  T
  CL-USER 3 > (defparameter *s2* 'foo)
  *S2*
  CL-USER 4 > (eq *s* *s2*)
  NIL

*S* has lost its home package and is thus not EQ to *S2*, sure, but
how do we explain this in terms of object identity?  Has the UNINTERN
operation changed the identity of *S* which once was the one and only
CL-USER::FOO but can't be anymore because this role is now occupied by
*S2*?

Did I miss some clarifying words in the standard?  Did I just manage
to confuse myself?

Thanks,
Edi.

PS: The UNINTERN entry warns about side effects which could harm
consistency, so maybe this is what they meant?


Gmane