Hi,
I've been away from ABCL for some time, so I ask your indulgence in case
I'm revisiting a familiar issue. I tried (SETF (UIOP:GETENV "foo")
"value") and got
Not (currently) implemented on ABCL: (SETF UIOP/OS:GETENV)
On investigation, I see that the JVM doesn't normally support setting
environment variables, but there are known ways to jimmy it into doing so:
https://stackoverflow.com/questions/318239/how-do-i-set-environment-variabl…
Would a PR to add such a hack to ABCL be welcome, or should I just make it
a local mod? Or is there another, recommended way of doing this?
-- Scott
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
16th European Lisp Symposium
In-Cooperation-With: ACM SIGLAN
Call for Participation
April 24-25, 2023
Startup Village, Amsterdam, Nederlands
https://www.european-lisp-symposium.org/2023
Sponsored by EPITA, DIRO, MLPrograms, Franz Inc., and SISCOG
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Recent News
~~~~~~~~~~~
Registrer now. Early bird discount closing soon!
Keynote details now available.
Important Dates
~~~~~~~~~~~~~~~
- Final papers due: April 9, 2023
- Early registration deadline: April 9, 2023
- Symposium: April 24-25, 2023
Scope
~~~~~
The European Lisp Symposium is a premier forum for the discussion and
dissemination of all aspects of design, implementation, and application
of any of the Lisp dialects, including Common Lisp, Scheme, Emacs
Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen,
Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage
everyone interested in Lisp to participate.
The 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
Keynotes
~~~~~~~~
##### Artificial Intelligence: a Problem of Plumbing?
-- Gerald J. Sussman, MIT CSAIL, USA
We have made amazing progress in the construction and deployment of
systems that do work originally thought to require human-like
intelligence. On the symbolic side we have world-champion
Chess-playing and Go-playing systems. We have deductive systems and
algebraic manipulation systems that exceed the capabilities of human
mathematicians. We are now observing the rise of connectionist
mechanisms that appear to see and hear pretty well, and chatbots that
appear to have some impressive linguistic ability. But there is a
serious problem. The mechanisms that can distinguish pictures of cats
from pictures of dogs have no idea what a cat or a dog is. The
chatbots have no idea what they are talking about. The algebraic
systems do not understand anything about the real physical world. And
no deontic logic system has any idea about feelings and morality.
So what is the problem? We generally do not know how to combine
systems so that a system that knows how to solve problems of class A
and another system that knows how to solve problems of class B can be
combined to solve not just problems of class A or class B but can
solve problems that require both skills that are needed for problems
of class A and skills that are needed for problems of class B.
Perhaps this is partly a problem of plumbing. We do not have
linguistic structures that facilitate discovering and building
combinations. This is a fundamental challenge for the
programming-language community. We need appropriate ideas for abstract
plumbing fittings that enable this kind of cooperation among disparate
mechanisms. For example, why is the amazingly powerful tree
exploration mechanism that is used for games not also available, in
the same system, to a deductive engine that is being applied to a
social interaction problem?
I will attempt to elucidate this problem and perhaps point at avenues
of attack that we may work on together.
##### Hedy: Gradual, Multi-Lingual, and Teacher-Centric Programming Education
-- Felienne Hermans, Vrije Universiteit Amsterdam, Nederlands
When kids learn to program they often use either a visual language
like Scratch, or a textual language like Python. While visual
languages are great for the first steps, children and educators often
want to move on to textual languages. However, early on, a textual
language and its error messages can be scary. Hedy aims to bridge this
gap with a programming language that is gradual, using different
language levels.
In level 1, there is hardly any syntax at all; printing is done with:
print hello!
At every level, new syntax and concepts are added, so learners do not
have to master everything at once. Hedy builds up to a subset of
Python including conditions, loops, variables, and lists.
To make learning as accessible as possible, Hedy also allows for the
use of localized keywords, f.e in Spanish: imprimir Hello! Hedy
(www.hedy.org) was launched in early 2020 and over 5 million Hedy
progams have been created to date, and has been translated into 46
languages.
##### A Language-Based Approach to Programming with Serialized Data
-- Michael Vollmer, School of Computing, University of Kent, UK
It is common for software running today to use object representations
fixed by the language runtime system; both the Java and Haskell
runtimes dictate an object layout, and the compiler must stick to it
for all programs. And yet when humans optimize a program, one of their
primary levers on performance is changing data representation. For
example, an HPC programmer knows how to pack a regular tree into a
byte array for more efficient access. Unfortunately, this is
error-prone, making it an undesirable way to achieve performance
optimization at the expense of safety and readability.
Furthermore, whenever a program receives data from the network or
disk, rigid insistence on a particular heap layout causes an impedance
mismatch we know as deserialization. Data represented in memory has
pointers and arbitrary, sparse layout, while data on disk is packed
contiguously, so data must be transformed from one form to another and
back.
Programming with serialized data is a technique for unifying the
in-memory and on-disk representations of data, where the serialized
form is used both on-disk and in-memory. This technique allows data
processing programs to skip the deserialization/reserialization steps
by operating directly on the data in its serialized form. It also
represents a principled approach to optimizing programs by compacting
data representations, which increases locality and minimizes
indirection.
In this talk, I will present a programming language, LoCal, for
programming with serialized data. I will also describe Gibbon, an
experimental compiler that automatically transforms functional
programs to operate on serialized data.
##### Run-Time Verification of Communication Protocols in Clojure
-- Sung-Shik Jongmans, Open Universiteit, Nederlands
To simplify shared-memory concurrent programming, languages have
started to offer core support for high-level communications
primitives, in the form of message passing though channels, in
addition to lower-level synchronization primitives. Yet, a growing
body of evidence suggests that channel-based programming abstractions
also have their issues.
The Discourje project aims to help programmers cope with channels and
concurrency bugs in Clojure programs, based on dynamic analysis. The
idea is that programmers write not only implementations of
communication protocols in their Clojure programs, but also
specifications. Discourje then offers a run-time verification library
to ensure that channel actions in implementations are safe relative to
specifications.
Programme Chair
~~~~~~~~~~~~~~~
Stefan Monnier, DIRO, Université de Montréal, Canada
Programme Committee
~~~~~~~~~~~~~~~~~~~
Mark Evenson, not.org, Austria
Marco Heisig, Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany
Ioanna Dimitriou, Igalia S.L., Germany
Robert Smith, HRL Laboratories
Mattias Engdegård
Marc Feeley, Université de Montréal, Canada
Marc Battyani, FractalConcept
Alan Ruttenberg, National Center for Ontological Research, USA
Nick Levine, RavenPack, Spain
Ludovic Courtès, Inria, France
Matthew Flatt, University of Utah, USA
Irène Durand, Université Bordeaux 1, France
Jay McCarthy, Brigham Young University, USA
Ambrose Bonnaire-Sergeant, Cisco
Christopher League, Long Island University, NY, USA
Pascal Costanza, Intel, Belgium
Christian Queinnec
Local Chair
~~~~~~~~~~~
Breanndán Ó Nualláin, Machine Learning Programs, Nederlands
--
Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info