freenode/#lisp - IRC Chatlog
Search
20:40:22
aeth
It depends on what you're going for, though. If it's common enough just defining a trivial function is probably the way to go. e.g. (defun hash-table-value-exists-p (key hash-table) (nth-value 1 (gethash key hash-table)))
20:41:56
aeth
But imo you should either do a function wrapping nth-value or a multiple-value-bind that ignores the values you don't need because either will be more self-documenting than just using nth-value.
20:44:25
araly
well for this time I'm just using the second value of a function once, but I will turn it into a function if it turns out I use it again after
20:45:51
aeth
For very trivial functions that are small and probably will never change, you can declare them inline above the function definition, e.g.: (declaim (inline hash-table-value-exists-p))\n(defun hash-table-value-exists-p (key hash-table)\n...
20:46:11
aeth
So there's basically no reason not to use trivial functions when it makes the code better. It's very idiomatic.
21:04:21
stylewarning
Has anybody worked on or thought about being able to write small snippets of inline C code in Lisp?
21:11:13
MichaelRaskin
Cmera (or how is it even written) would even allow you to generate C from Lispy syntax
21:19:14
aeth
I generate a limited subset of GLSL from s-expressions. Nothing really stops me from finishing GLSL and then also adding what syntax C has on top of that.
21:20:53
aeth
The strings can even be made at compile time from the expressions. It would greatly complicate your build process, though.
21:23:36
aeth
It wouldn't be truly "inline" because the C compiler wouldn't be cooperating, unless you built the C compiler yourself, which is totally doable non-portably in SBCL.
21:24:22
stylewarning
I mean, sometimes it's annoying to write Lisp code that looks identical to C, except it's 10x more verbose and still less performant.
21:24:45
stylewarning
Maybe it would be nice to just compile a C function to some anonymous library and dynamically load it or something, I don't know.
21:25:09
aeth
Are the internals exposed by SBCL (e.g. define-vop) sufficient to write a C compiler with?
21:26:31
aeth
That would be an interesting alternative to relying on foreign C, although it wouldn't be portable.
21:28:25
aeth
I don't really have issues with verbose low-level CL, though. The thing that's the most verbose compared to C-style-syntax is probably aref, but I even have a with-accessors equivalent for that now in with-2D-array-accessors. https://gitlab.com/zombie-raptor/zombie-raptor/blob/184e235be3974ebc3b062b3fb94559c2e15797f9/util/array.lisp#L106-144
21:28:59
aeth
The result is something that's more verbose than using aref directly, but probably still more readable.
21:29:30
aeth
e.g. https://gitlab.com/zombie-raptor/zombie-raptor/blob/184e235be3974ebc3b062b3fb94559c2e15797f9/render/gl.lisp#L180-197
21:30:47
stylewarning
aeth: maybe because you don't read enough bitwise arithmetic and prefer things spelled out because a DSL doesn't make sense for you
21:31:47
aeth
stylewarning: well e.g. I prefer something like this for a common use case of bit operations: https://gitlab.com/zombie-raptor/zombie-raptor/blob/184e235be3974ebc3b062b3fb94559c2e15797f9/math/boolean-set.lisp
21:42:25
stylewarning
the fact of the matter is that C has a good DSL for many kinds of bitwise operations, and you can trust a C compiler to produce good code for those
21:42:41
stylewarning
this is also not to say that you can't write such in Lisp, which was what I was originally suggesting
21:43:21
stylewarning
pjb`: lisp is more mathematical, and hides the machine representation of data pretty well.
21:43:38
stylewarning
pjb`: C is consequently not very mathematical, and lets you interpret bits however you'd like
21:44:14
stylewarning
anyway, this is non-interesting, because it's a usual rehash of what everybody already knows
21:45:22
aeth
pjb`: There would be advantages to writing either C strings or s-expressions that trivially map to C-strings directly in CL source, which was the original point.
21:45:50
aeth
("C strings" as in strings of C, not the hideous representation of strings that C has.)
21:48:13
aeth
pjb`: I wonder if it would be better to back the C memory in an emulated C by CFFI's C array representation or by static-vectors rather than CL arrays. Then you get interoperability with C libraries, too.
21:49:15
aeth
static-vectors would work best, then, because you could trivally substitute normal CL arrays instead of using static-vectors, but share most of the code.
21:50:08
pjb`
My take is to shift the C environment into the lisp environment (and therefore uplift it to the same safety level as lisp).
21:50:27
pjb`
So you wouldn't do FFI, you would just compile the foreign C library with my future compiler and obtain lisp object code.
21:51:03
pjb`
aeth: what is C interoperability? As long as you have the C sources (which is the case most of the time), you could just recompile them in lisp.
21:52:17
aeth
One example is 3D graphics APIs as well as input/window/sound/etc. A lot of graphical CL apps use cl-opengl with cl-sdl2 for this reason, although in theory you could probably write directly to the OS APIs and bypass the need for something like SDL2 as a dependency.
21:53:10
aeth
A graphics toolkit ported to cl-opengl or (in the future) cl-vulkan could, if you don't care about not feeling native (and only macOS users seem to care about that), bypass most, but not all C.
21:54:13
stylewarning
pjb`: out of curiosity, have you written much code that has to process terabytes of numerical data in Lisp?
21:54:16
aeth
Alternatively, a future revision to the CL standard could include all of these OS APIs into the standard itself. Then the implementors would deal with it and anything written in CL itself would technically be pure CL without touching C APIs.
21:55:14
aeth
(Some things that require OS C APIs probably could be moved into the language, though.)
21:56:18
aeth
pjb`: In the near future you could compile, via a written-in-Lisp compiler, a Lisp-like language to SPIR-V and send that to the GPU. You'd still have to deal with the OpenCL/OpenGL/Vulkan/whatever API, though.
21:59:44
aeth
For the forseeable future, though, you'll want: access to some POSIX things not in the CL standard, access to the GPU, windowing/input, sound, and a few other things.
22:00:20
aeth
And if you want portability, on Windows you can't use the syscalls and expect them not to break. You'd have to use CFFI there.
22:00:30
pjb`
aeth: the only argument is proprietary binary libraries. The key word above was SOURCE.
22:01:56
pjb`
aeth: yes, but on MS-Windows, you use different CL implementations anyways. You don't run the same CL executable both on MS-Windows and on Linux (unless you use the Linux-in-Windows-10 thingy.
22:02:28
White_Flame
pjb`: I, too, have a dream of C-in-Lisp compilation & native API access. Have you done any work on it so far?
22:02:33
pjb`
aeth: the idea here is that a CL implementation could provide a native access to syscalls, without calling libc.
22:02:51
pjb`
White_Flame: so far, only the pre-processor is implemented, and I started working on the parser.
22:04:31
pjb`
If we become billionnaire, I promise to fork some of it to complete this C to CL compiler :-)
22:14:39
aeth
The way I'd see graphical Lisp in the near future is: write to SDL and OpenGL, but be flexible about the SDL part. Eventually, the input/windowing part could be replaced with a more Lispy solution. I suppose OpenGL is just so complex that pjb's solution would be necessary for Lisp purists, although eventually migrating over to the simpler Vulkan might present a simpler future solution.
22:16:03
aeth
What will probably happen is either SDL will still be in use on non-Linux platforms or there will be an SDL-replacement that uses the native APIs and some OSes will need CFFI for those (but there wouldn't be any C *dependencies* that need to be shipped)
22:16:51
aeth
All of this is still quite low level. If you wanted McCLIM or whatever, there'd probably be a new OpenGL backend to it eventually.
22:16:53
pjb
Intel is creating its own GPUs. There will be some competition in the backends. So perhaps libraries like OpenGL will strive.
22:17:33
White_Flame
is there any software out there that doesn't use opengl/d3d/etc types of libraries?
22:17:42
pjb
But for computing jobs, I guess people will choose to use the native SDKs. (ie. program directly in cuda). In that case, OpenGL is irrelevant.
22:18:29
aeth
White_Flame: There are three ways to do a GUI. Browser (or electron), 3D APIs, or directly using the 2D APIs. Unless you're doing very simple things, you want the 3D APIs.
22:20:37
aeth
White_Flame: The future is (hopefully) any language you want compiled to SPIR-V and run in OpenCL or Vulkan compute (they're both from Khronos, so there'd be a heavy overlap in features)
22:21:10
aeth
You'd still have the OpenCL or Vulkan API, but a lot of the toolchain could be pure Lisp, such as your own compiler to SPIR-V.
22:22:05
White_Flame
there seemed to be an implication of running graphics without libs like ogl, which read strangely
22:23:12
aeth
White_Flame: pjb was talking about potentially compiling stuff like libmesa in a C-on-CL compatibility layer.
22:25:43
theemacsshibe[m]
Speaking of JS, are there any JavaScript interpeters/compilers for Common Lisp?
22:26:15
theemacsshibe[m]
I had a nice bot for a thing but cloudflare got in the way some time last night.
22:26:17
aeth
Yes, there is at least one, but it doesn't keep up with modern JS in features or performance.
22:26:51
aeth
JS is a language that cannot be fast without JIT. I guess you could "JIT" a language that is transpiled to CL because CL can recompile functions at runtime, though.
22:27:45
White_Flame
I talk about it relatively frequently. The usual target for runtime recompilation has been CLOS dispatch
22:28:29
pjb
theemacsshibe[m]: deep in the old sources of firefox/mozillay, there's the sources of an implementation of an old JavaScript in CL.
22:28:33
aeth
White_Flame: I think you talk about JITing a CL implementation. I'm talking about using runtime recompilation in an existing AOT CL to emulate JIT in a language like JS or Lua that is being compiled to CL.
22:28:54
pjb
theemacsshibe[m]: probably you'll have to locate an old version, because I guess they've pruned it.
22:29:17
White_Flame
aeth: there's actually little difference, and CLOS dispatch is an example of what you describe
22:29:37
pjb
theemacsshibe[m]: it would be a nice project to take the latest javascript standard, and write an implementatio of it in CL targetting CL.
22:30:14
pjb
theemacsshibe[m]: an alternative project would be to write a LLVM backend in CL, and use the Javascript -> LLVM compiler.
22:30:57
aeth
pjb: If you wrote an LLVM backend in CL, you get way more than just JS. You also get Clasp.
22:32:15
aeth
Unfortunately, the Linux kernel doesn't quite compile with clang. If it did, you could have Linux-on-CL
22:35:52
White_Flame
but yeah, you can always pick a subset that something happens to use, instead of trying to reimplement all of it
22:37:09
White_Flame
I also shudder to imagine implementing an interface from CL through x86 interpreter through JSLinux through node.js
22:37:15
pjb
the only problem with the 68000 is that it loses information on some traps, so you cannot write a multitasking OS on it. There was a unix workstation using 2 68000 with one running one clock late to kludge this bug.
3:10:31
White_Flame
do any of the lisp webservers do protocol sharing on their port? ie, if the first line isn't valid http, then pass it off to another protocol handler?