[HN Gopher] April, an APL Compiler for Common Lisp [video]
___________________________________________________________________
April, an APL Compiler for Common Lisp [video]
Author : tosh
Score : 59 points
Date : 2020-09-10 17:45 UTC (1 days ago)
(HTM) web link (youtube.com)
(TXT) w3m dump (youtube.com)
| ncmncm wrote:
| Without watching the video, can we guess correctly that "for
| Common Lisp" means "in Common Lisp"? Or is it really meant for
| use within Common Lisp programs?
| phantomics wrote:
| April is usable within Common Lisp. When writing a CL program,
| you can invoke APL code on arrays. For example:
|
| (april-c "{[?][?],(3[?]2*8)[?]3 1 2[?][?]}" (opticl:read-png-
| file "/path/to/image.png"))
|
| This snippet uses the opticl library to load a PNG file, and
| then uses April to count the number of unique colors in the
| image. Consider the amount of code this would take in CL.
| smabie wrote:
| It would be cool if it was implemented as a reader macro
| instead of just passing a string to a function.
| phoe-krk wrote:
| Do it yourself! (Implementation loosely based on
| phantomics' comment below.) (defun april-
| reader (stream char) (declare (ignore char))
| `(april ,(read stream t nil t))) (set-
| macro-character #\[?] #'april-reader)
| Avshalom wrote:
| You're probably gonna want something more complicated
| than that. Glancing at the github page it looks like at
| least the following need to be dealt with:
| (april "apl code") ; and april-f (april (with
| (stuff)) "apl code") ; and april-f (april-c "apl
| code" (input)) (april-c (with (stuff)) "apl code"
| (input))
| phoe-krk wrote:
| Yes, the above is a trivial implementation; handling
| multi-form input would need to be much more complex.
| Thankfully, for simple one-liners, you'll likely want
| either April literals (implemented above) or April
| anonymous functions, both of which won't take additional
| arguments; you should be able to implement both as simple
| reader macros.
| phantomics wrote:
| Wouldn't be too hard to do, someone in the video suggested
| a #[?] reader macro followed by APL. Like take '#[?]string'
| then expand that to '(april "string")'.
|
| But April has many ways of passing options and external
| data for the compiled code to operate upon, and
| implementing a reader macro system that would support all
| those parameters would be complicated and require
| developers to learn a bunch of new syntax in order to use
| April with reader macros.
| phantomics wrote:
| Since the video's quite long, here are some basics on April.
|
| Repo: https://github.com/phantomics/april
|
| April compiles APL to Common Lisp. It has almost all of the
| lexical functions and operators featured in Dyalog APL, the
| leading commercial APL interpreter and the most featureful APL
| implementation. It has many more features than the FOSS GNU APL,
| which is based on the old IBM APL2.
|
| Dyalog APL's source code is about 500KLOC according to Dyalog's
| staff. GNU APL is over 100KLOC per its homepage. April's .lisp
| files currently stand at 6350LOC.
|
| APL interpreters have traditionally been hard to connect to
| external data sources. Because APL is typically implemented as an
| interpreter, any connection to a database or other external
| system needs to be built into that interpreter as a plugin. April
| is called from within a Lisp program and you can pass it any
| array-formatted data. You can use CL libraries to read from any
| database or other source, format the data as an array and pass it
| to April for processing.
|
| April takes some features from the k language, including
| ($[oneorzero;1;0]) if-statements and (g-{[a;b;c]a+bxc} [?]
| g[1;2;3]) n-argument functions.
|
| April is extensible - you can easily create an extension to the
| language with more functions and operators, and you can also re-
| implement the utility functions that are used to parse and
| compile the language. The language is designed from the ground up
| to support extension. There is also a framework to extend the
| compiler to optimize common idioms, for instance [?][?],200 200
| 200[?][?]9 is optimized to just fetch the last row-major-ordered
| element of the big array instead of actually taking the time and
| memory to ravel and reverse it.
|
| The second half of the video features a preview of a hardware
| startup called Bloxl that's powered by Common Lisp and April.
| Bloxl is a big transparent block wall with LEDs inside the light
| up to create pixel graphics. April was used to build the
| animations that run on Bloxl.
| jonahx wrote:
| > Dyalog APL's source code is about 500KLOC according to
| Dyalog's staff. GNU APL is over 100KLOC per its homepage.
| April's .lisp files currently stand at 6350LOC.
|
| What accounts for this discrepancy?
| mlochbaum wrote:
| A ways into the video it says the core Dyalog interpreter is
| about 100KLOC, with the rest being GUI code and interop such
| as file handling and formats, cross-platform support, .NET
| interop, and so on. If the 100k figure surprises you then
| what you are missing is just how deep array optimization is.
| For example, searching through an array will use an SSSE3
| table lookup for 1-byte elements, a different table for
| 2-byte elements, and several different kinds of hash tables
| for other types. I tried to give a sense of the scale of this
| sort of thing in the first slide of my Dyalog '19 talk on
| Reductions (https://www.youtube.com/watch?v=TqmpSP8Knvg). You
| can write pages and pages of code and still there will be a
| way to speed up a common operation substantially.
|
| By working on multidimensional arrays, APL expands the range
| of computations that are accessible to optimization. I think
| the writer of a scalar compiler like C would generally be
| happy making a single loop as fast as possible. APL
| immediately makes the implementer think about what happens if
| there are many axes (each of which is equivalent to a nested
| loop) even if the later axes (inner loops) are small.
| Avshalom wrote:
| -Common Lisp vs C/C++
|
| -April implements the language and just punts to CL for all
| the I/O and system level stuff. Like it doesn't have to
| implement a REPL, or a line editor or APL workspace
| files/array stores.
| jonahx wrote:
| Thanks. I'm guessing (based on my knowledge of J and all
| its optimizations/special forms) that Dyalog APL would
| still be more performant too? I didn't see it mentioned on
| the GH README.
| phoe-krk wrote:
| Yes, the talk mentions that Dyalog is still much more
| performant, given how much time and effort has been spent
| on optimizing it.
| kazinator wrote:
| > _any connection to a database or other external system needs
| to be build into that interpreter as a plugin._
|
| Guess: that could be the general area where Dyalog is burning
| most of its alleged, monstrous 500 KLOC.
| phantomics wrote:
| Thanks for posting my presentation, April's been great fun to
| write.
___________________________________________________________________
(page generated 2020-09-11 23:00 UTC)