clisp-list — general help and discussion

Re: [clisp-list] make install fails: #error "Please include config.h first."

[Stephen B. <ste...@gm...>]

On Sat, 02 Nov 2024 19:38:06 +0100 Stephen Berman via clisp-list <cli...@li...> wrote:

> Today I updated my local git repo of clisp to the latest commit
> 0e67ff47e and successfully configured and built clisp, but install
> failed with many errors like this (I've attached a file with the full
> shell output of make install):
>
> In file included from /usr/include/string.h:462,
>                  from /home/steve/src/clisp/build_20241102/gllib/string.h:41,
>                  from clisp.c:23:
> /home/steve/src/clisp/build_20241102/gllib/strings.h:42:3: error: #error "Please include config.h first."
>    42 |  #error "Please include config.h first."
>       |   ^~~~~
>
> A web search found many reports with this error, but I could not find
> anything that made make install succeed.  My system is GNU/Linux with
> gcc-14.2.0 and glibc-2.40.  My last build of clisp, where make install
> also succeeded, was last May 21, using the latest git commit at that
> time; that system was with gcc-13.2.0 and glibc-2.39.
>
> I'd be grateful for any help in solving this issue.

I just updated again and now make install succeeded too.  Perhaps the
problem I had yesterday was fixed by this commit?

* 79d82fcb6..: Bruno Haible 2024-11-03 build: Build the clisp driver program without gnulib, part 2.

Steve Berman

Re: [clisp-list] make install fails: #error "Please include config.h first."

[Stephen B. <ste...@gm...>]

On Sat, 02 Nov 2024 19:38:06 +0100 Stephen Berman <ste...@gm...> wrote:

> Today I updated my local git repo of clisp to the latest commit
> 0e67ff47e and successfully configured and built clisp, but install
> failed with many errors like this (I've attached a file with the full
> shell output of make install):

Apparently the list server deleted the attachment; I can post the full
output inline if desired.

Steve Berman

[clisp-list] make install fails: #error "Please include config.h first."

[Stephen B. <ste...@gm...>]

Today I updated my local git repo of clisp to the latest commit
0e67ff47e and successfully configured and built clisp, but install
failed with many errors like this (I've attached a file with the full
shell output of make install):

In file included from /usr/include/string.h:462,
                 from /home/steve/src/clisp/build_20241102/gllib/string.h:41,
                 from clisp.c:23:
/home/steve/src/clisp/build_20241102/gllib/strings.h:42:3: error: #error "Please include config.h first."
   42 |  #error "Please include config.h first."
      |   ^~~~~

A web search found many reports with this error, but I could not find
anything that made make install succeed.  My system is GNU/Linux with
gcc-14.2.0 and glibc-2.40.  My last build of clisp, where make install
also succeeded, was last May 21, using the latest git commit at that
time; that system was with gcc-13.2.0 and glibc-2.39.

I'd be grateful for any help in solving this issue.

Steve Berman

Re: [clisp-list] array limits on arm ampere

[C H. <bum...@gm...>]

I get the same issue on a laptop (hp probook).

it seems that 4194303  is the max. I found possible using the OP code.

Habs


On Wed, 24 Jan 2024 at 23:32, Don Cohen <
don...@is...> wrote:

>
> I've recently started using oracle cloud and I
> notice that I can't allocate an array of >= 4M characters.
>
> On intel with
>  *features*
> (:REGEXP :WILDCARD :SYSCALLS :I18N :LOOP :COMPILER :CLOS :MOP :CLISP
> :ANSI-CL
>  :COMMON-LISP :LISP=CL :INTERPRETER :LOGICAL-PATHNAMES :MT :SOCKETS
>  :GENERIC-STREAMS :FFI :GETTEXT :UNICODE :BASE-CHAR=CHARACTER :WORD-SIZE=64
>  :PC386 :UNIX)
> (length (make-array  (* 1024 1024 4)
>         :element-type 'character
>         :fill-pointer t :adjustable t))
> => 4194304
>
> but on ampere with
> *features*
> (:READLINE :REGEXP :WILDCARD :SYSCALLS :I18N :LOOP :COMPILER :CLOS :MOP
> :CLISP
>  :ANSI-CL :COMMON-LISP :LISP=CL :INTERPRETER :LOGICAL-PATHNAMES :SOCKETS
>  :GENERIC-STREAMS :SCREEN :FFI :GETTEXT :UNICODE :BASE-CHAR=CHARACTER
>  :WORD-SIZE=64 :UNIX)
> *** - string too long: desired length 4194304 exceeds the supported
> maximum length
>
> Both say
> array-dimension-limit
> 4294967296
> (interestingly, one MORE than impnotes says should be the value
> for a 64 bit cpu)
>
>
> _______________________________________________
> clisp-list mailing list
> cli...@li...
> https://lists.sourceforge.net/lists/listinfo/clisp-list
>

[clisp-list] array limits on arm ampere

[<don...@is...>]

I've recently started using oracle cloud and I
notice that I can't allocate an array of >= 4M characters.

On intel with
 *features*
(:REGEXP :WILDCARD :SYSCALLS :I18N :LOOP :COMPILER :CLOS :MOP :CLISP :ANSI-CL
 :COMMON-LISP :LISP=CL :INTERPRETER :LOGICAL-PATHNAMES :MT :SOCKETS
 :GENERIC-STREAMS :FFI :GETTEXT :UNICODE :BASE-CHAR=CHARACTER :WORD-SIZE=64
 :PC386 :UNIX)
(length (make-array  (* 1024 1024 4)
        :element-type 'character
        :fill-pointer t :adjustable t))
=> 4194304

but on ampere with
*features*
(:READLINE :REGEXP :WILDCARD :SYSCALLS :I18N :LOOP :COMPILER :CLOS :MOP :CLISP
 :ANSI-CL :COMMON-LISP :LISP=CL :INTERPRETER :LOGICAL-PATHNAMES :SOCKETS
 :GENERIC-STREAMS :SCREEN :FFI :GETTEXT :UNICODE :BASE-CHAR=CHARACTER
 :WORD-SIZE=64 :UNIX)
*** - string too long: desired length 4194304 exceeds the supported maximum length

Both say
array-dimension-limit
4294967296
(interestingly, one MORE than impnotes says should be the value
for a 64 bit cpu)

Re: [clisp-list] Mildly amusing diagnostic wording.

[Pascal B. <pj...@in...>]

> On 8 Nov 2023, at 08:07, Kaz Kylheku <ka...@ky...> wrote:
> 
> [1]> (loop (loop-finish)) 
> 
> *** - (LOOP-FINISH) is possible only from within LOOP
> The following restarts are available:
> ABORT :R1 Abort main loop 
> 
> :)
> 

This is an error in the error message. (issue a bug report)
The LOOP operator introduces two kinds of loops:
- simple loops as the one you wrote,
- extended loops.

LOOP-FINISH is only available in extended loops, not in simple loops.

If you want to use loop-finish, you may add a do keyword to make it an extended loop:
(loop do (loop-finish))


-- 
__Pascal J. Bourguignon__

[clisp-list] Mildly amusing diagnostic wording.

[Kaz K. <ka...@ky...>]

[1]> (loop (loop-finish)) 

*** - (LOOP-FINISH) is possible only from within LOOP
The following restarts are available:
ABORT :R1 Abort main loop 

:)

Re: [clisp-list] clisp on gitlab

[Erik A. <aue...@un...>]

Hi,

On 23.07.23 02:20, Raymond Toy wrote:
> FYI, clisp is now on gitlab, not sourceforge: 
> https://gitlab.com/gnu-clisp/clisp and the last change was 4 days ago.
> 
> I didn't know this until I was just setting up gmane on thunderbird and 
> read the clisp list there.
Thanks for this information!

The CLISP web page still does not mention GitLab, only SourceForge.
I've checked "http://clisp.org", "https://clisp.sourceforge.io/",
and "https://www.gnu.org/software/clisp/" right now.

It would be great if the CLISP project would update this information.
Thanks in advance!

Best regards,
Erik

Re: [clisp-list] clisp on gitlab

[Raymond T. <toy...@gm...>]

On 7/22/23 5:20 PM, Raymond Toy wrote:
> FYI, clisp is now on gitlab, not sourceforge: 
> https://gitlab.com/gnu-clisp/clisp and the last change was 4 days ago.
>
> I didn't know this until I was just setting up gmane on thunderbird 
> and read the clisp list there.
>
Oops.  Wrong to address.

[clisp-list] clisp on gitlab

[Raymond T. <toy...@gm...>]

FYI, clisp is now on gitlab, not sourceforge: 
https://gitlab.com/gnu-clisp/clisp and the last change was 4 days ago.

I didn't know this until I was just setting up gmane on thunderbird and 
read the clisp list there.

Re: [clisp-list] unwanted new line

[Sam S. <sd...@gn...>]

> * Don Cohen <qba...@vf...3-vap.pbz> [2023-07-14 02:15:04 +0000]:
>
> (setf list '("abc" "def" "qwe
> rty
> uiop" "zxc"))
>
> (with-output-to-string (s)(loop for x in list do (format s "~s~c" x #\tab)))
> "\"abc\"        \"def\"
> \"qwe
> rty
> uiop\"  \"zxc\" "
>
> Why is there an extra new line before the list element that contains
> the newlines?
> Is there some way to suppress it ?

https://clisp.sourceforge.io/impnotes/faq.html#faq-pp-newline
;-)
https://clisp.sourceforge.io/impnotes/faq.html#faq-fine



-- 
Sam Steingold (https://aphar.dreamwidth.org/) on Pop 22.04 (jammy) X 11.0.12101004
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://thereligionofpeace.com https://camera.org https://honestreporting.com
Booze is the answer. I can't remember the question.

[clisp-list] unwanted new line -- never mind

[<don...@is...>]

I see I asked the same question in 2016 !!
And the answer is the same now -- print-pretty is t


Don Cohen writes:
 > 
 > (setf list '("abc" "def" "qwe
 > rty
 > uiop" "zxc"))
 > 
 > (with-output-to-string (s)(loop for x in list do (format s "~s~c" x #\tab)))
 > "\"abc\"        \"def\"
 > \"qwe
 > rty
 > uiop\"  \"zxc\" "
 > 
 > Why is there an extra new line before the list element that contains
 > the newlines?
 > Is there some way to suppress it ?

[clisp-list] unwanted new line

[<don...@is...>]

(setf list '("abc" "def" "qwe
rty
uiop" "zxc"))

(with-output-to-string (s)(loop for x in list do (format s "~s~c" x #\tab)))
"\"abc\"        \"def\"
\"qwe
rty
uiop\"  \"zxc\" "

Why is there an extra new line before the list element that contains
the newlines?
Is there some way to suppress it ?

[clisp-list] clisp.org points to SourceForge, not GitLab

[Erik A. <aue...@un...>]

Hi,

it seems to me as if the clisp.org (and www.gnu.org/software/clisp) site
show outdated information by only mentioning the SourceForge Mercurial
repository and the SourceForge bug tracker.  Bug reports are directed
to the SourceForge bug tracker, neither to a mailing list nor the GitLab
issue tracker.

It seems to me as if this is no longer good advice, and perhaps it might
be helpful to update those web pages.

(I tried to report a bug and followed the directions from clisp.org to
add it to the SourceForge bug tracker.  I did not receive any reply,
so I do not know if it has been seen.  I have seen another recent bug
report there, which might have been overlooked, but I do not know that.)

Kind regards,
Erik
-- 
A distributed system is one in which the failure of a computer you didn't
even know existed can render your own computer unusable.
                        -- Leslie Lamport

Re: [clisp-list] FYI: Cygwin package is crippled: no FFI.

[Ken B. <kb...@co...>]

On 1/12/2023 3:03 AM, Kaz Kylheku wrote:
> Hi All,
> 
> Just a heads up that whoever is maintaining the CLISP
> package for Cygwin seems not to have built it with
> FFI support.
> 
> The FFI package doesn't exist.
> 
> I'm trying to use an old program of mine, and oops!

This belongs on the Cygwin list.  I'll follow up there.

Ken

[clisp-list] FYI: Cygwin package is crippled: no FFI.

[Kaz K. <ka...@ky...>]

Hi All, 

Just a heads up that whoever is maintaining the CLISP
package for Cygwin seems not to have built it with
FFI support.

The FFI package doesn't exist. 

I'm trying to use an old program of mine, and oops!

[clisp-list] [CfP] ELS 2023, 16th European Lisp Symposium, April 24-25, Amsterdam

[Didier V. <di...@lr...>]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
		     16th European Lisp Symposium

			   Call for Papers

			  April 24-25, 2023
		Startup Village, Amsterdam, Nederlands

	     https://www.european-lisp-symposium.org/2023

		     Sponsored by EPITA and DIRO
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Important Dates
~~~~~~~~~~~~~~~
- Submission deadline: February 26, 2023
- Author notification: March    26, 2023
- Final papers due:    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


Technical Program
~~~~~~~~~~~~~~~~~
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 4 pages for demonstrations of
  tools, libraries, and applications.

* Tutorials: abstracts of up to 4 pages for in-depth presentations
  about topics of special interest.

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
link http://www.easychair.org/conferences/?conf=els2023.

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.


Programme Chair
~~~~~~~~~~~~~~~
Stefan Monnier, DIRO, Université de Montréal Canada

Programme Committee
~~~~~~~~~~~~~~~~~~~
TBA


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

[clisp-list] [CfPart] ELS 2022, 15th European Lisp Symposium, March 21-22, Porto.

[Didier V. <di...@lr...>]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
		     15th European Lisp Symposium

			Call for Participation

			  March 21-22, 2022
		    FEUP, Porto, Portugal & Online
		   In cooperation with ACM SIGPLAN

	     https://www.european-lisp-symposium.org/2022

	      Sponsored by EPITA, Franz Inc., and SISCOG
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Important News
~~~~~~~~~~~~~~~
- Full programme now online
- Invited speakers below
- Registrations are open


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


Invited talks
~~~~~~~~~~~~~
Building SICMUtils, the Atelier of Abstractions -- Sam Ritchie

SICMUtils is a Clojure library designed for interactive exploration of
mathematical physics. It is simultaneously a work of persuasive
writing, a collection of essays on functional pearls and computational
ideas, a stable of workhorse functional abstractions, and a practical
place to work and visualize algorithms and physical systems, on a
server or in the browser.

How do you build a library like this? This talk will go through the
architecture of SICMUtils, based on many of the ideas of "additive
programming" from Gerald Sussman and Chris Hanson's latest book,
Software Design for Flexibility. We'll look at surprising examples of
the system becoming easier to extend over time. Clojure's embrace of
its host platform lets us use the best modern work in Javascript for
visualization, while keeping the horsepower of our servers for real
work. Lisp's particular elegance will shine throughout.


Creating a Common Lisp Implementation -- Robert Strandh

Being dissatisfied with the way current Common Lisp implementations
are written, and with the duplication of system code between different
implementations, we started the SICL project in 2008. The initial idea
was to create modules that the creators of Common Lisp implementations
could use to create a complete system from an initial minimal core.
But this idea was unsatisfactory because it required each module to be
written in a subset of Common Lisp. So instead, we decided to use the
full language to implement these modules, effectively making them
useless to an implementation using traditional bootstrapping
techniques. We therefore decided to also create a new Common Lisp
implementation (also named SICL), that could use those modules.

A crucial element is a bootstrapping technique that can handle these
modules. In this spirit, we have developed several modules, including
an implementation of CLOS which is also an important element of
bootstrapping. Lately, we have increased our level of ambition in that
we want to extract those modules as separate (and separately
maintained) repositories, which requires us to deal with code during
bootstrapping that was not specifically written for SICL.

In our talk, we describe this evolution of ambition, and its
consequences to bootstrapping, in more detail. We also give an
overview of several new techniques we created, some of which have been
published (at ICL and ELS) and some of which have not. Finally, we
discuss the future of the project, and other projects for which we
imagine SICL to be a base.


Lisp as Renaissance Workshop: A Lispy Tour through Mathematical
Physics -- Sam Ritchie

Lisp is an exquisite medium for the communication of computational
ideas. From our most accurate observations of physical reality up
through chemistry, biology, and cognition, the universe seems to be
computing itself; modeling and simulating these systems in machines
has led to incredible technological wealth.

Deep principles and beautiful abstractions seem to drive these
systems, but they have always been hard to discover; and we are
floundering at the computational frontiers of intelligence, synthetic
biology and control systems for our climate. The only way to push
forward is to build powerful tools that can communicate and teach.

This talk will take a tour through SICMUtils, a Lisp system designed
as a workshop for conducting serious work in mathematical physics and
sharing those explorations in a deeply interactive, multiplayer way.
The library’s growth parallels our human scientific history; hopefully
tools like this will help us write the next chapter.



Programme Chair
~~~~~~~~~~~~~~~
Jim Newton - EPITA Research Lab (LRDE), France

Programme Committee
~~~~~~~~~~~~~~~~~~~
Philipp Meier, Nubank
Ioanna M. Dimitriou H., Igalia
Mikhail Raskin, Technical University of Munich
Nick Levine, RavenPack
Adrien Pommellet, LRDE, EPITA
Marco Heisig, Friedrich-Alexander-Universität Erlangen
Alberto Riva, Bioinformatics Core, ICBR, University of Florida
Marco Antoniotti, DISCo, Università degli Studi di Milano-Bicocca
Nicolas Neuss, Friedrich-Alexander-Universität Erlangen
Christophe Rhodes, Google UK
Irène Anne Durand, LaBRI, University of Bordeaux
Ralf Moeller
Breanndán Ó Nualláino, University of Amsterdam
Marc Battyani, Fractal Concept
Pascal Costanza, Intel
Sky Hester, Private Consultant

-- 
Resistance is futile. You will be jazzimilated.

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

[clisp-list] [Extended Deadline] 15th European Lisp Symposium

[Didier V. <di...@lr...>]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
		     15th European Lisp Symposium

			   Call for Papers

			  March 21-22, 2022
		    FEUP, Porto, Portugal & Online
		  In co-location with <Programming>

	     https://www.european-lisp-symposium.org/2022

		  Sponsored by EPITA and Franz Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Important Dates
~~~~~~~~~~~~~~~
- Submission deadline ***EXTENDED***: January  30, 2022
- Author notification: February 21, 2022
- Final papers due:    March     7, 2022
- Symposium:           March 21-22, 2022


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


Technical Program
~~~~~~~~~~~~~~~~~
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 4 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.

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
link http://www.easychair.org/conferences/?conf=els2022.

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.


Programme Chair
~~~~~~~~~~~~~~~
Jim Newton - EPITA Research Lab (LRDE), France

Programme Committee
~~~~~~~~~~~~~~~~~~~
Philipp Meier, Nubank
Ioanna M. Dimitriou H., Igalia
Mikhail Raskin, Technical University of Munich
Nick Levine, RavenPack
Adrien Pommellet, LRDE, EPITA
Marco Heisig, FAU Erlangen-Nürnberg
Alberto Riva, Bioinformatics Core, ICBR, University of Florida
Marco Antoniotti, DISCo, Università degli Studi di Milano-Bicocca
Nicolas Neuss, Friedrich-Alexander-Universität Erlangen
Christophe Rhodes, Google
Irène Anne Durand, LaBRI, University of Bordeaux
Ralf Moeller
Breanndán Ó Nualláino, University of Amsterdam
Marc Battyani, Fractal Concept
Pascal Costanza, Intel

-- 
Didier Verna <di...@el...>
ELS Steering Committee

[clisp-list] [Last CfP] 15th European Lisp Symposium, March 21-22 2022, Porto

[Didier V. <di...@lr...>]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
		     15th European Lisp Symposium

			   Call for Papers

			  March 21-22, 2022
		    FEUP, Porto, Portugal & Online
		  In co-location with <Programming>

	     https://www.european-lisp-symposium.org/2022

		  Sponsored by EPITA and Franz Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Important Dates
~~~~~~~~~~~~~~~
- Submission deadline: January  23, 2022
- Author notification: February 21, 2022
- Final papers due:    March     7, 2022
- Symposium:           March 21-22, 2022


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


Technical Program
~~~~~~~~~~~~~~~~~
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 4 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.

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
link http://www.easychair.org/conferences/?conf=els2021.

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.


Programme Chair
~~~~~~~~~~~~~~~
Jim Newton - EPITA Research Lab, France

Programme Committee
~~~~~~~~~~~~~~~~~~~
Philipp Meier, Nubank
Ioanna M. Dimitriou H., Igalia
Mikhail Raskin, Technical University of Munich
Nick Levine, RavenPack
Adrien Pommellet, EPITA Research Lab
Marco Heisig, FAU Erlangen-Nürnberg
Alberto Riva, Bioinformatics Core, ICBR, University of Florida
Marco Antoniotti, DISCo, Università degli Studi di Milano-Bicocca
Nicolas Neuss, Friedrich-Alexander-Universität Erlangen
Christophe Rhodes, Google
Irène Anne Durand, LaBRI University of Bordeaux
Ralf Moeller
Breanndán Ó Nualláin
Marc Battyani, Fractal Concept
Pascal Costanza, Intel, Belgium


-- 
Didier Verna

[clisp-list] [CfP] 15th European Lisp Symposium, March 21-22 2022, Porto, Portugal

[Didier V. <di...@lr...>]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
		     15th European Lisp Symposium

			   Call for Papers

			  March 21-22, 2022
		    FEUP, Porto, Portugal & Online
		  In co-location with <Programming>

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

			  Sponsored by EPITA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Important Dates
~~~~~~~~~~~~~~~
- Submission deadline: January  23, 2022
- Author notification: February 21, 2022
- Final papers due:    March     7, 2022
- Symposium:           March 21-22, 2022


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


Technical Program
~~~~~~~~~~~~~~~~~
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 4 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.

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
http://www.easychair.org/conferences/?conf=els2021

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.


Programme Chair
~~~~~~~~~~~~~~~
Jim Newton - EPITA Research Lab (LRDE), France

Programme Committee
~~~~~~~~~~~~~~~~~~~
tba

-- 
Resistance is futile. You will be jazzimilated.

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

Re: [clisp-list] FP using CL

[Pascal B. <pj...@in...>]

Le 07/05/2021 à 04:44, Jean Louis a écrit :
> * Kaz Kylheku <ka...@ky...> [2021-05-06 19:11]:
>>> It is easy to find examples of Common Lisp as functional language,
>>> rather hard to find procedural examples.
>>
>> Where are you looking? It's hard to find examples of Common Lisp as
>> a procedural language in a book or tutorial that is ideologically
>> geared toward functional.
>>
>> If you look in real code, it's not hard to find procedural coding.
>>
>> Just now, I headed to github and tried to think of some known CL project.
>>
>> For some reason, the word *cl-who* popped into my head, probably
>> because my mind drifted toward authors and I was thinking "who" do
>> I look for?
>>
>> And so, I searched for cl-who and immediately landed on this:
>>
>> https://github.com/edicl/cl-who/blob/master/who.lisp
>>
>> Whoa! Look, it's full of setf, loop, incf, nreverse ...
> 
> IMHO I was expecting more style without `defun'.

DEFUN is the operator to define functions.

Programs are usually made of functions, and there's a "main" or 
"top-level" that is called when the program starts, which further calls 
other functions.

That said, it's your lucky day, Common Lisp also deals with all other 
top-level forms.

Usually, top-level forms are defining forms such as defun, but also 
defvar, defparameter, deftype, defmacro, defconstant, defclass, 
defgeneric, defmethod, define-condition, etc.  Those defining forms let 
you instruct the compiler to create objects of various categories and 
name them.

But Common Lisp also allows any other expression as top-level form.  In 
that case, if the source file is compiled, the expressions are collected 
by the compiler in an initialization function that is automatically 
called at load time (when the compiled file is loaded), or, if the 
source file is loaded, they are evaluated at that time, one after the other.

Therefore, it is possible to write a program, which will rather be 
called a "script" in that case, without using DEFUN.

BUT, this is entirely orthogonal with whether your code is written in 
functional or procedural style, or any other style (declarative, OOP, 
whatever).

For example, a file containing:

     #!/usr/local/bin/clisp -q -norc -ansi
     (let ((*print-right-margin* 16))
       (pprint (mapcar (function string-upcase)
                       (mapcar (function namestring)
                               (directory "*.*")))))

named list-files, and with the execution access right (chmod +x 
list-files) would be a script written without DEFUN, in functional style.
(apart, you may argue, PPRINT, but consider that's just an operator in 
the IO monad).


     [pjb@despina org.xquartz:0 tmp 36Gi]$ ~/list-files

     ("/PRIVATE/TMP/QUUX.LISP"
      "/PRIVATE/TMP/BAR.LISP"
      "/PRIVATE/TMP/FOO.LISP")

     [pjb@despina org.xquartz:0 tmp 36Gi]$ find * -prune -type f -ls
      65058164      0 -rw-r--r--   1 pjb      wheel           0 May  7 
05:12 bar.lisp
      65058163      0 -rw-r--r--   1 pjb      wheel           0 May  7 
05:12 foo.lisp
      65034432      4 -rw-------   1 root     wheel          36 May  7 
04:43 fseventsd-uuid
      65058165      0 -rw-r--r--   1 pjb      wheel           0 May  7 
05:12 quux.lisp

     [pjb@despina org.xquartz:0 tmp 36Gi]$


-- 
__Pascal Bourguignon__

Re: [clisp-list] FP using CL

[Jean L. <bu...@gn...>]

* Kaz Kylheku <ka...@ky...> [2021-05-06 19:11]:
> > It is easy to find examples of Common Lisp as functional language,
> > rather hard to find procedural examples.
> 
> Where are you looking? It's hard to find examples of Common Lisp as
> a procedural language in a book or tutorial that is ideologically
> geared toward functional.
> 
> If you look in real code, it's not hard to find procedural coding.
> 
> Just now, I headed to github and tried to think of some known CL project.
> 
> For some reason, the word *cl-who* popped into my head, probably
> because my mind drifted toward authors and I was thinking "who" do
> I look for?
> 
> And so, I searched for cl-who and immediately landed on this:
> 
> https://github.com/edicl/cl-who/blob/master/who.lisp
> 
> Whoa! Look, it's full of setf, loop, incf, nreverse ...

IMHO I was expecting more style without `defun'.

I do understand and get the point that in your examples while there
are many functions defined they don't just return the value but also
change various states, including they could be changing global
state. And that belongs to imperative programming style.

Though in Lisp it would be rare to find a program without `defun'
definitions.




Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://stallmansupport.org/
https://rms-support-letter.github.io/

[clisp-list] Fwd: FP using CL

[Pascal B. <pj...@in...>]

-------- Message transféré --------
Subject: Re: [clisp-list] FP using CL
To: Duke Normandin <duk...@gm...>
References: <202...@gm...>
From: Pascal Bourguignon <pj...@in...>
Message-ID: <917...@in...>
Date: Sun, 2 May 2021 02:03:18 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) 
Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <202...@gm...>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit

Le 01/05/2021 à 20:00, Duke Normandin a écrit :
> Noob here!
> 
> All of my previous non-pro, hobbyist hacking experience has been imperative.
> I want to give FP a shot using CL.
> Problem: I don't seem to grok how to start the process of creating a CL program using **just** functions.
> 
> I mean, I can flowchart an imperative-styled program w/o too much difficulty.
> Need to grok how to do same in FP-style with CL.
> 
> I can learn the CL/Scheme/et al syntax, but it's the "Thinking in FP" that's killing me. :)
> 
> Any leads to relevant online resource(s)? TIA ...

I would advise to start with Bachus's fundational paper.

https://dl.acm.org/doi/pdf/10.1145/359576.359579
https://www.youtube.com/watch?v=FxcT4vK01-w
https://www.youtube.com/watch?v=OxuPZXXiwKk


Now, you don't have to use *just* functions, but indeed the idea is to 
build functions from other functions using function operators (such as 
the function composition operator for example), instead of definiting 
the functions detailing each operation element by element.

A function takes elements from a source set, and return elements in an 
image set.  The usual programming will give an expression of the image 
element "in function of" the element of the source set.


Let's define an affine function a:

a : ℤ → ℤ
     x ↦ 2x+1

or in lisp:

     (defun a (x)
       (+ (* 2 x) 1))


But if we define the function 2* (or double):

2* : ℤ → ℤ
      x ↦ 2x

and the function 1+ (or successor):

1+ : ℤ → ℤ
      x ↦ x+1

Then instead of defining a giving an expression element by element:

a : ℤ → ℤ
     x ↦ 2x+1

we can write a functional expression:

a = 1+ ∘ 2*

Using the composition operation between two functions f∘g(x) = f(g(x))

So:  a(x) = 1+ ∘ 2* (x) = 1+(2*(x)) = 1+(2*x) = 1+2*x = 2*x+1

Note that Common Lisp already has a function 1+ (and 1- for x-1).
We only need to define double and compose:

     (defun compose (f g) (lambda (x) (funcall f (funcall g x))))

     (defun times (n) (lambda (x) (* x n)))

     (defmacro define (fname fexpression)
        `(progn
           (declaim (ftype (function (t) t) ,fname))
           (setf (symbol-function ',fname) ,fexpression)))

     (define double (times 2))
     (define a (compose (function 1+) (function double)))

     (mapcar (function a) (iota 10))
     --> (1 3 5 7 9 11 13 15 17 19)

Note how I used mapcar, and not a procedural dotimes, so I get the
results for all the elements of the input set (iota 10) at once,
instead of computing and getting the result element by element:

     (dotimes (i 10)
       (print (a i)))

     1
     3
     5
     7
     9
     11
     13
     15
     17
     19

Now the question is to collect a library of functional operators that
will help us writing such functional expressions easily and
expressively.  And not all functions in the CL library are conductive
to easy building functional expressions from them.  So we may also
have to rewrite some library functions.


So here is another example; we could write:

     (defun minus (n) (lambda (x) (- x n)))
     (defun partial (f x)
       (lambda (y) (funcall f x y)))

     (mapcar
      (compose (partial (function reduce) (function +))
               (lambda (x)
                 (mapcar (lambda (f) (funcall f x))
                         (list (function identity)
                               (compose (minus 10) (function a))))))
      (iota 10))
     --> (-9 -6 -3 0 3 6 9 12 15 18)

     (list (function identity)
           (compose (minus 10) (function a)))

     --> (#<Compiled-function identity #x30000012D5FF>
         #<ccl:compiled-lexical-closure (:internal compose) #x30200275E99F>)

builds a list of 2 functions, identity = x ↦ x
and a-10 = x ↦ (2*x)+1-10 = 2*x-9


           (lambda (x)
             (mapcar (lambda (f) (funcall f x))
                     (list (function identity)
                           (compose (minus 10) (function a)))))


is a function that takes an argument and applies it to each function
of the list, returning a list of results:

          ((lambda (x)
             (mapcar (lambda (f) (funcall f x))
                     (list (function identity)
                           (compose (minus 10) (function a)))))
           5)
         --> (5 1)

partial is a function that takes a function and an argument, and
returns a function that takes a second argument and call the first
function with the two arguments.  It's a partial application of the
function.

So:  (funcall (partial f x) y)  == (funcall f x y)

Therefore:     (partial (function reduce) (function +))
returns a function that sums a list of numbers:

     (funcall (partial (function reduce) (function +)) (list 1 2 3 100))
     --> 106

So we can use it to compose it with the previous lambda which returns
a list of 2 numbers:

     (funcall (compose (partial (function reduce) (function +))
                       (lambda (x)
                         (mapcar (lambda (f) (funcall f x))
                                 (list (function identity)
                                       (compose (minus 10) (function a))))))
              5)
     --> 6

and use the composition in a map of the set of integers from 0 to 9:

     (mapcar
      (compose (partial (function reduce) (function +))
               (lambda (x)
                 (mapcar (lambda (f) (funcall f x))
                         (list (function identity)
                               (compose (minus 10) (function a))))))
      (iota 10))
     --> (-9 -6 -3 0 3 6 9 12 15 18)


-- 
__Pascal Bourguignon__

-- 
__Pascal Bourguignon__

Re: [clisp-list] FP using CL

[Kaz K. <ka...@ky...>]

On 2021-05-05 23:28, Jean Louis wrote:
> * Kaz Kylheku <ka...@ky...> [2021-05-03 22:41]:
>> On 2021-05-01 11:00, Duke Normandin wrote:
>> > Noob here!
>> >
>> > All of my previous non-pro, hobbyist hacking experience has been
>> > imperative.
>> > I want to give FP a shot using CL.
>> > Problem: I don't seem to grok how to start the process of creating a
>> > CL program using **just** functions.
>> 
>> The good news is that pretty much "nobody" does that. Common Lisp is a
>> multi-paradigm language.
> 
> It is easy to find examples of Common Lisp as functional language,
> rather hard to find procedural examples.

Where are you looking? It's hard to find examples of Common Lisp as
a procedural language in a book or tutorial that is ideologically
geared toward functional.

If you look in real code, it's not hard to find procedural coding.

Just now, I headed to github and tried to think of some known CL 
project.

For some reason, the word *cl-who* popped into my head, probably
because my mind drifted toward authors and I was thinking "who" do
I look for?

And so, I searched for cl-who and immediately landed on this:

https://github.com/edicl/cl-who/blob/master/who.lisp

Whoa! Look, it's full of setf, loop, incf, nreverse ...

Next, I just recalled a the existence of a Common Lisp program that
was part of someone's Ph. D. thesis about solving certain
geometric shape arrangement puzzles, namely tangrams. Aha,
here it is:

https://github.com/lambdamikel/Common-Lisp-Tangram-Solver

That's academic stuff doing some lofty algorithms, including
some approaches that must be novel if they fetched a Ph. D.

Academia is obsessed with functional nowadays. Still, can we
find imperative coding in it?

Let this be the first file I select for inspection:

https://github.com/lambdamikel/Common-Lisp-Tangram-Solver/blob/main/src/main/covering3.lisp

I see loops there. Loops are not inherently non-functional though;
sometimes their variable stepping is not relevant. I.e. they
basically emulate the math sigma notation, which isn't procedural.

More importantly, I see this in the file:

       (let ((ox (decode-ccw (orientation x)))
             (oy (decode-ccw (orientation y))))

         (when (eq ox :clockwise)
           (orientate-counterclockwise x))

         (when (eq oy :counterclockwise)
           (orientate-clockwise y))

         ...)

This is a let form with multiple body arguments, which means
they are being evaluated for an effect. The value of the first
(when ...) form is not being returned; it is ignored. Which
means that (oreintate-counterclockwise x) has an effect on the
object denoted by x.

It looks like the orientations of objects x and y are being
decoded, and then these objects are tweaked with an opposite
orientation, probably in order to normalize them in order to
reduce the number of cases later, or something.

See? You can do Ph. D. level work in computational geometry,
accompanied by imperative code written in Lisp.

I feel I could sit here all day, and easily land into one
Common Lisp source after another that is full of effectful
programming.

Cheers ...