freenode/#lisp - IRC Chatlog
Search
4:54:39
pjb
nitrix: also notice how I said that C was a botched derivative of lisp (like most other current programming language).
4:54:52
pjb
nitrix: this means that you can do anything those languages can do, rather trivially in lisp.
4:55:43
oni-on-ion
=)... well also, we can provide a little guidance to the lisp way of things, if applicable. certainly we can do shaolin kung defu, but what is the practical way to walk on spears?
4:56:50
pjb
If you look for a language that goes a little beyond lisp, you could take Haskell. Even prolog is completely embeddable trivially in lisp.
4:57:18
aeth
pjb: eh, a while back someone who was working on a Prolog said that prolog isn't easily embeddable in Common Lisp
4:59:07
nitrix
Also, I'll be the own judge of whether or not my questions makes sense. I understand what I'm asking isn't specifically Common Lisp, but it's not like I'm against it either. I'm glad to hear how CL does things and if I can make sense of it, I'll definitely get behind it. For now, I have to understand it first instead of being sent to ##lisp and dismissed.
4:59:11
oni-on-ion
its just that CL makes 40mb exes. wonder whats in there that C doesnt have ? lisp still links to all the same libs, too. strange!
4:59:43
LdBeth
nitrix: that’s even good, because I’ve looked tons of Haskell projects teaches how to write a lisp
4:59:43
pjb
C executables link with a 20 MB libc, which is about the same size as the libecl library.
5:00:13
pjb
So you can either use an image based system, and have your library "statically linked" or you can use ecl, and libecl.so.
5:00:21
aeth
pjb: no, I mean, there are apparently some well-known obstacles for efficiently embedding Prologs within other languages, and someone here a while back was talking about those
5:00:48
aeth
I am not an expert in Prolog implementing (I've barely been exposed to Prolog) so I won't claim to know exactly the issues were...
5:01:02
pjb
oni-on-ion: we could implement the syscall ABI in CL implementations and do entirely without libc.
5:01:03
oni-on-ion
the least amount of baggage is pure assembly of course, then next slimmest-to-system closest-to-metal is C.
5:01:59
nitrix
LdBeth: Choosing the semantics is the hard part. I want to better understand the choices behind CL and their implications.
5:02:14
oni-on-ion
i think linux abi has been stable for a while. windows 10 64bit ships with binary compat (WSL)
5:02:25
pjb
aeth: of course, this is work to maintain the syscall ABI on all target platforms. Hence we defer to libc maintainers…
5:02:54
aeth
oni-on-ion: Linux syscalls are stable, is what I mean. They're treated as an external API. Syscalls to e.g. NT are treated as an internal API
5:03:19
LdBeth
nitrix: there’s not much semantic difference between CL and Scheme, except for continuation part
5:04:35
nitrix
Alright. Thanks for the help. Tiny progress was made but it quickly turned into chaos. I'll give it a try another day.
5:05:04
aeth
LdBeth: If CL implementations had an API that said "force TCO" and an API that exposed some form of continuations, you could basically just do a bunch of syntax macros and trivially do a Scheme in CL afaik
5:05:28
aeth
LdBeth: The continuations can't be as full as in Scheme because of the conditions system in CL afaik, but they could probably be complete enough to run a Scheme runtime in a CL runtime
5:06:00
pjb
LdBeth: only it's very difficult to have both continunations and block/return catch/throw.
5:06:30
oni-on-ion
okay i wasnt sure -- i heard a lot about the debates between scheme and CL about #f/nil/()/etc. BUT!! i swear i've seen a lisp file once, that was compilable on three different lisps. scheme, elisp and CL i think.
5:06:40
aeth
pjb: But you could probably make it happen if the continuations were for embeddable languages like Scheme rather than for the entire CL runtime
5:07:08
LdBeth
pjb: I believe Chez has accomplished that by means of lexical continuation and dynamic continuation
5:07:41
pjb
aeth: yes. However one point of embedding a language in the other is to be able to mix them rather freely. Calling CL from scheme and calling scheme from CL.
5:08:36
aeth
pjb: Yes, which means you now have two wrappers of Scheme-in-CL functions, one for procedures and one for predicates. predicates return t/nil which become #t/#f, where #f is some symbol that's not nil. Regular procedures assume nil is '()
5:09:21
oni-on-ion
my conclusion is that the true ultimate computer language is simply binary and ascii. everything else is a subset
5:09:29
aeth
And, if you really wanted to, calling Scheme from CL could just always turn #f into nil
5:10:09
aeth
LdBeth: The point is that there should only be one runtime for managed (i.e. GCed) languages because interoperating between multiple GCed languages is messy
5:10:39
aeth
LdBeth: The other point is that SBCL is pretty fast, so you might get, for free(*), one of the fastest, if not the fastest, Scheme implementations (* not really free, see continuations)
5:11:39
aeth
Well, actually, I can't really wait on them, since what everyone's waiting on here is my code.
5:13:34
LdBeth
I mean CL and Scheme is still close enough to interpolate with only the help of macro
5:16:24
pjb
And yes, those questions (efficiency, calling one language from another, etc), are actually old questions. Nowadays, we have fast processors, gigabytes of RAM, even faster multi-core GPUs, and the internet providing us with more libraries than we can use. There's little reason to try to use a library from a foreign language anymore.
5:17:05
pjb
In the 80s, it could have been a good idea to embed scheme or prolog in lisp to re-use their code. Nowadays, we probably already have two CL libraries doing the same.
5:17:11
oni-on-ion
'from a foreign language' ? do you mean using a foreign language to access, or accessing the library *in* a foreign lang?
5:18:06
oni-on-ion
on one side i had started using C for the lib that talks to all the C libs, then i noticed my high level language file doing the same thing with ffi was 1/3 the size
5:18:08
pjb
The later option is preferable (and started implementing a C->CL compiler to do that with GNU emacs), but note that we already have Hemlock.
5:19:23
pjb
Then we can write our own emacs extensions in CL, but we keep using the GNU emacs maintainers' work and third party emacs lisp code.
5:20:10
oni-on-ion
i'd rather write in elisp =) there isnt much lacking that CL would bring to the table, aside from performance and even longer identifiers
5:50:23
pjb
oni-on-ion: it was actually better without asdf and quicklisp: you had to locate lisp code, download it, read it to learn how to load it. You would write a loader script if there wasn't one. You would enter into it and learn more than nowadays. Nowadays, you just quickload a system, and call one or two functions in it, and that's it. You don't learn anything.
5:51:37
oni-on-ion
pjb, hmm, true! that sounds like its close to how nice smalltalk felt with ChangeSets
5:56:34
oni-on-ion
i think ive still got some of the webserver code that i used defsystem with, around 2011
5:57:12
oni-on-ion
im reflecting on whether these conveniences are perverting the pristine shimmering purity of CL
5:59:53
no-defun-allowed
in this case, not cause it'd be bad, but it's probably not as good as ASDF or a de-facto standard
6:06:19
no-defun-allowed
That makes perfect sense, since CL obviously compiles to .o files and can be linked and assembled just like a C program.
6:07:55
aeth
if you don't have a CL daemon that takes stdin from the shell just so you can load libraries via makefiles and bash, you don't know what you're missing
6:10:54
stylewarning
"The problem with defending the purity of Common Lisp is that CL is about as pure as a cribhouse whore. We don't just borrow paradigms; on occasion, CL has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new functions."
6:25:14
Nilby
Indeed, I spent part of today rifling through the pockets of code in other languages, just to "borrow" them for CL.
6:32:47
Nilby
In this I pilferd Clojure's group-by, which was probably implemented in Lisp before Lisp was.
6:49:23
no-defun-allowed
well we don't intend to give them back so is it borrowing? also, they still have it too
6:50:50
shka_
anyway, assimilating foreign ideas in programming is arguably more powerful then coming up with your own
6:51:33
no-defun-allowed
if it's anything CLOS and the MOP, it's assimilating foreign ideas and abstracting and extending them to the extent it's basically new
8:51:20
aeth
The only valid CL style is to have a separate foo.h.lisp for every foo.lisp and in that file do stuff like (declaim (ftype (function ((unsigned-byte 32) (signed-byte 32)) (values (signed-byte 32))) foobar))
9:17:13
aeth
saturn2: I already did that... https://gitlab.com/zombie-raptor/zombie-raptor/blob/41e9e6553a83015d67e14aad5b46f60dcf40b862/util/types.lisp
9:39:01
aeth
I guess a hypothetical foo.h.lisp would be the worst of both package.lisp and package-at-the-top styles
10:01:54
aeth
That wouldn't work because we export symbols, not functions. Well, it would work, just with some unexpected edge cases.
10:04:41
asdf_asdf_asdf
Hi. [SBCL] http://www.sbcl.org/manual/ How using sb-alien... write equivalent to "void*"? I try: "(define-alien-type (* void))". Doesn't works.
10:53:05
schweers
asdf_asdf_asdf: maybe just (*)? anyway, is there a reason you’re using sb-alien instead of CFFI? or some ohter portablility layer?
10:53:27
shka_
https://github.com/numcl/numcl this got my interest, it looks pretty good on the surface, what do you guy thinks?
10:59:30
asdf_asdf_asdf
Manual: The foreign type specifier (* foo) describes a pointer to an object of type foo. A pointed-to type foo of t indicates a pointer to anything, similar to void * in ANSI C. A null alien pointer can be detected with the sb-alien:null-alien function.
11:09:22
pjb
aeth: now of course, nothing prevents you to defined a module abstraction, where you could declare that you'd export from the module either the function or the variable or the type, or whatever else kind of binding, and when you import the module, you'd get only that. That would be independent from packages…
11:28:15
schweers
has anyone here used the code coverage facility of CCL? I set ccl:*compile-code-coverage* to t, recompiled my sources and ran the tests. So far so good. When I run CCL:REPORT-COVERAGE, I get an error which claims that NIL is not of the expected type STRUCTURE.
13:02:05
pfdietz
stylewarning: that quote was originally by James Nicoll, and it was about English, not Common Lisp. https://en.wikiquote.org/wiki/James_Nicoll
13:39:47
asdf_asdf_asdf
In manual: http://www.sbcl.org/manual/ is (slot ...). I want pass function WindowProc as alien-type-function. How it do?
15:36:01
beach
asdf_asdf_asdf: Given what you are trying to do, there are probably a lot fewer people than usual that are able to help you.
15:44:35
asdf_asdf_asdf
Bike, yes CALLBACK, code is here: https://docs.microsoft.com/en-us/windows/desktop/learnwin32/your-first-windows-program
15:45:58
pjb
Something like (cffi:defcallback my-win-proc …) (setf (lpfnWndProc wc) (cffi:callback my-win-proc))
15:53:04
beach
asdf_asdf_asdf: If you are trying to learn Common Lisp, I am afraid you are going about it the wrong way. But perhaps I am mistaken and you are an experienced Common Lisp programmer.
16:15:10
Nilby
They're not exported, so probably shouldn't be used. i.e. you have to use them with 2 colons as sb-alien::define-alien-callback.
16:19:58
Nilby
Here's some examples of Windows GUI code: https://github.com/fjames86/ftw/blob/master/ftw.lisp https://github.com/Zulu-Inuoe/winutil https://github.com/jdunrue/graphic-forms
16:24:14
oni-on-ion
asdf_asdf_asdf, did you see that link i posted ? or are you just kind of on your own little adventure here
16:33:18
jkordani
minion: memo for schweers did you figure out what was going on with your code coverage issue?
16:36:18
jfe
i have a plain function that inputs and outputs slists. i want to use the *result* of that function in a macro, but i'm not sure how to do it. is there a trick for doing this?
16:38:10
makomo
jfe: a macro's body is just normal lisp code that can use whatever it likes. just call your function within your macro's body.
16:41:34
sjl_
something like `(labels ((test (tuple) ,(predicate-bind predicate (rel-schema rA) 'tuple)))) ...
16:43:36
Bike
if i'm reading this correctly, the predicate-bind function needs an actual schema object
16:44:09
sjl_
but the rel isn't there at macroexpansion time. all the macro actually gets is what you give it: the symbol REL
16:46:54
jfe
asdf_asdf_asdf: it's as sjl_ describes it. i need the value of 'rel at macroexpansion time but i have no way to get it.
16:46:58
Bike
macro functions are evaluated at compile time. at compile time, there is no schema. so what you want isn't really possible. if i understand correctly.
16:47:07
sjl_
I don't know what this is actually trying to *do* (it looks like some kind of query language) so it's tough to say. If I had to guess, I'd guess that what you actually need is 1. a function that takes a schema (your rel thing) and a query (the list (= 4 :foo)) and does your query.
16:47:24
sjl_
2. A macro that's a thin layer on top of that function, so you don't have to manually quote that list
16:49:48
sjl_
Doing it like that is nice because you end up not only with the macro, but also with the function, which you can MAP, ALEXANDRIA:CURRY, etc etc
16:51:10
makomo
indeed. a lot of the time you should treat your macros as "the cherry on top" which just provides nice and convenient syntax and does all of its work by forwarding to your functional abstractions
16:51:23
sjl_
e.g. I'd imagine the macro would look like (defmacro rel-select (rA query) `(perform-rel-select ,rA ',query))
16:53:46
jfe
a query might look like '(< 3 :foo). then i convert this expression to '(lambda (tuple) < 3 (nth <'foo' column number> tuple))