<no-defun-allowed>
(expt x 2) may be more specific but it is longer
gravicappa has joined #lisp
oni-on-ion has joined #lisp
<beach>
Good morning everyone!
<LdBeth>
Morning, beach
oni-on-ion has quit [Remote host closed the connection]
oni-on-ion has joined #lisp
oni-on-ion has quit [Client Quit]
<asarch>
Thank you!
<asarch>
Thank you very much no-defun-allowed! :-)
dacoda has joined #lisp
MightyJoe has joined #lisp
oni-on-ion has joined #lisp
cyraxjoe has quit [Ping timeout: 276 seconds]
oni-on-ion has quit [Remote host closed the connection]
<asarch>
One very very stupid off-question: can you use the full of Maxima with only Common Lisp?
marusich has quit [Ping timeout: 268 seconds]
<beach>
Sure. What else would you need?
oni-on-ion has joined #lisp
<beach>
asarch: Though, check out Climaxima that loke has been working so hard on. It uses McCLIM (which is written in Common Lisp) for its rendering.
<no-defun-allowed>
I would hope so, since Maxima is written entirely in CL
phax has quit [Quit: Leaving]
oni-on-ion has quit [Remote host closed the connection]
oni-on-ion has joined #lisp
abhixec has joined #lisp
oni-on-ion has quit [Remote host closed the connection]
oni-on-ion has joined #lisp
oni-on-ion has quit [Remote host closed the connection]
oni-on-ion has joined #lisp
nirved_ has joined #lisp
oni-on-ion has quit [Remote host closed the connection]
oni-on-ion has joined #lisp
oni-on-ion has quit [Remote host closed the connection]
oni-on-ion has joined #lisp
<asarch>
Thank you!!!
<asarch>
Thank you very much guys! :-)
oni-on-ion has quit [Remote host closed the connection]
nirved has quit [Ping timeout: 258 seconds]
<asarch>
Oh, that's for Linux :-(
mindCrime has quit [Ping timeout: 258 seconds]
<nitrix>
Hello. I've been reading a lot about Lisp and the various dialects lately (I even got my copy of SICP). I'm really loving the whole minimal syntax, homoiconic, the ability to build the language bottom-up and give/change the meaning of any symbol, including the evaluation itself (in the case of macros).
<nitrix>
I feel like I'm getting closer to some kind of nirvana, but somehow the memory aliasing / mutation / GC parts of most of these dialects still feels very dirty to me.
<nitrix>
Are there lisps focusing on immutability?
<LdBeth>
GG
<no-defun-allowed>
Scheme and Racket are typically immutable.
<LdBeth>
immutability is essentially GC
<no-defun-allowed>
Not sure what memory aliasing is, but you need GC for closures from memory.
<no-defun-allowed>
Think of functions like Y which create circles.
<LdBeth>
Otherwise you must have infinite memory
<nitrix>
LdBeth, good catch. I used GC too narrow minded there.
<nitrix>
I suppose my biggest problem is the ability for two symbols to share the same "storage"; as in mutating one affects the other.
dacoda has quit [Ping timeout: 250 seconds]
<nitrix>
In C, this would having two pointers with the same value, thus both pointing at the same memory location.
<nitrix>
no-defun-allowed, not sure where the term originates from but the C community refers to it as aliasing memory.
<LdBeth>
nitrix: it sounds like you want single assignment style
<nitrix>
Correct. The problem is as soon as you do that, you more or less lose closures, don't you?
<no-defun-allowed>
Depends on what you want closures for.
<nitrix>
Like, the only semantics that makes sense from lambda if you take that route is for (lambda (x) (y)) to capture the value of y by coping it.
<nitrix>
s/coping/copying
<LdBeth>
Closure is mainly for variable capture, and the only reason to capture variable is to update it
<LdBeth>
Otherwise you just assign it to global environmental
<nitrix>
I can think of a second use, which would be creating partial applied functions (if you're familiar with some functional programming concepts)
nanoz has joined #lisp
techquila has quit [Read error: Connection reset by peer]
<LdBeth>
That’s no difference to FORTH words
* nitrix
sighs
<LdBeth>
Every forth word takes a stack and return a stack
<LdBeth>
Every curried function takes a function and return a function
techquila has joined #lisp
<nitrix>
I'm starting to think my desire for immutability comes from not having a clear understanding of symbols and their evaluation.
<nitrix>
(Very probable :P)
atgreen has quit [Ping timeout: 250 seconds]
<nitrix>
In a Lisp-1, are they semantically the same as C pointers?
<LdBeth>
If you mean function pointer, yes
anewuser has quit [Quit: anewuser]
<beach>
nitrix: If you are looking for immutability, Common Lisp (which is the subject of this channel) is not for you. I suggest you look at some functional programming language instead. Common Lisp is a multi-paradigm language, and modern Common Lisp uses object-oriented programming (using CLOS generic functions) a lot.
<beach>
nitrix: I am not sure why you are focusing on symbols and the way they are evaluated.
<nitrix>
beach: In all honesty, I do not have a strong preference between mutability or immutability on a day-to-day basis. I think I'm more trying to understand the implications of both for someone developing a dialect or wanting to adopt an existing one.
libre-man has quit [Ping timeout: 246 seconds]
nowhere_man has quit [Ping timeout: 245 seconds]
<beach>
nitrix: Like I said, this channel is dedicated to Common Lisp, so we don't much discuss other dialects (existing or new ones), other than if a compiler for such a dialect were to be written in Common Lisp.
<nitrix>
beach, suppose I have the symbols x and y. Does Common Lisp or some other lisp, allows for x to become some sort of entangled with y such that incrementing the value of one increments the other?
<nitrix>
Let's take Common Lisp then since it's the most popular and probably where I should start :)
<LdBeth>
nitrix: we use symbol macro for that
<beach>
nitrix: That would not be possible, but you can have symbol macros that might make it look like that.
<nitrix>
Oh interesting. That would require a small change in usage though, no? Like (x) for the macro to expand to whatever pointer chasing it needs to do?
<beach>
nitrix: No, you have the wrong model of how things work.
pierpal has joined #lisp
<beach>
nitrix: The evaluator simply replaces the reference to *y* with a reference to *x* and evaluates the replacement instead.
<nitrix>
I see. So define-symbol-macro's purpose seems to be precisely to modify what happens during the evaluation of a given symbol.
<LdBeth>
No
<LdBeth>
It happens at read time
<nitrix>
I tried to guess before beach :P
<beach>
LdBeth: It does not. It happens at compile time.
<beach>
nitrix: Yes, you are sort of right.
<aeth>
If you want immutability, defstruct has :read-only slots so you could just make every slot read-only. It absolutely will *not* be efficient, though, because no one writes this way so no implementation optimizes this.
<nitrix>
Okay, but you see, this is already a really big piece to me. That means that, unless you meddle with macros, symbols are consistent.
<aeth>
defstruct in general is how you do weird non-idiomatic things
<LdBeth>
I mean before eval, it actually “macro expand time”
<nitrix>
As in, you assign them a value and it's just a mapping in the environment from the name to its designated value and that's it.
<nitrix>
Evaluating the symbol gives you the value. That's elegant, that I can get behind :)
<pjb>
nitrix: notice that the homoiconicity in scheme is remote. You have to use special operators to convert syntax objects into sexps and vice-versa in scheme macros.
ym has quit [Remote host closed the connection]
<pjb>
nitrix: I would say that scheme doesn't have a pure homoiconicity. Only the other lisp have it.
<aeth>
pjb: I think you mean portable Scheme, nothing stops Schemes from having defmacro (or define-macro)
<beach>
nitrix: This is getting too noisy, so I'll stop now.
<pjb>
Yes, I talking about standards.
<nitrix>
beach, I'm sure that's an invaluable reference and I bookmarked it for later. Sadly, it's not very useful to me as I lack the foundation necessary to make sense of it.
<beach>
nitrix: If you want to learn more about Common Lisp, I recommend #clschool for newbie questions.
<nitrix>
As I build an intuition I'll go back to it.
<beach>
nitrix: Again, your model is too simplistic. Common Lisp typically compiles to native code, and symbols that designate lexical variables no longer exist at run time.
<pjb>
nitrix: aliasing poses no problem in lisp and languages where similarly the values are typed, not the variables. The problem with aliasing in C, is that the two identical pointers can be stored in variables of different pointer types. Otherwise, having two references to the same object can only pose a problem in multi-threaded applications, if you don't take care to synchronize accesses.
<pjb>
But in the case of multi-thread, this problem occurs even with a single reference!
<aeth>
nitrix: a symbol itself is essentially a pointer... but what it points to isn't really important, it could just as easily be a number (but then that would complicate accessing symbol-associated things like its symbol-plist, etc.)
libre-man has joined #lisp
<pjb>
Even if your CL implementation doesn't have a native or byte-code compiler, it still has to implement minimal compilation, which includes macroexpansion and taking note of special declarations.
<aeth>
Every CL implementation is afaik at least a bytecode compiler in practice
<pjb>
I think it's wrong to think of symbols as pointers. Instead, think of them as _names_.
<aeth>
pjb: well, I usually think of them as numbers
<pjb>
You're entitled to your messy brains.
<nitrix>
pjb, I much prefer that.
<aeth>
pjb: 'foo is in my brain 2578394... Well, actually it's probably #xff34e34 or whatever since it's probably a pointer, but that's a detail
<nitrix>
So, conceptually at least, it's associative, right? There's an association between a symbol (its name) and some value. Evaluating the symbol resolves to that value.
<nitrix>
Now, what happens if I have, let's say:
<nitrix>
(define n 42) (define (foo x y)) (foo n n)
<nitrix>
If my function foo starts mutation x, does y changes?
<nitrix>
*mutating
<nitrix>
If I had a body. I didn't give it any but we can pretend :)
<LdBeth>
If you mean output parameter, no that would not work
<pjb>
nitrix: you're asking a scheme question here. Better ask in #scheme or ##lisp (for comparative lisp).
shifty has joined #lisp
<pjb>
nitrix: in Common Lisp, arguments are passed by value. So the function doesn't know that the value it receives comes from a variable or from an expressiosn.
<LdBeth>
nitrix: unless n is a boxed value such a a cons, passing n to a function won’t mutate it
<aeth>
oh I see the question
<pjb>
nitrix: most lisp values are mutable. Only the numbers and the characters are immutable.
<nitrix>
I'm asking because even though `foo` has two parameters, `x` and `y`, the function was called with the same `n` argument twice, so I'm wondering if the two "names" starts sharing the same value now.
<aeth>
You probably meant something like this? (defvar *n* 42) (defun foo (x y) (setf x 7) (values x y)) (foo *n* *n*)
oni-on-ion has joined #lisp
<aeth>
That will return 7 and 42, and *n* will be 42
<nitrix>
aeth, *n* stays 42?
<pjb>
nitrix: and aeth assumes one meaning of your expression "foo starts mutation x" which is not English, and is not clear. Do you want to mutate the parameter X, or do you want to mutate the value bound to the parameter X?
<aeth>
nitrix: every defun/lambda/let creates a new lexical scope
<pjb>
*N* stays bound to the same object.
<aeth>
nitrix: You could think of it like a series of hash tables, where if it's not in the most local hash table, it looks up one level, and then up one level, etc.
<nitrix>
pjb, Well, that's where it becomes interesting because I didn't know there was a distinction between both. C has that distinction, I didn't know CL did too.
<pjb>
nitrix: C is quite close to lisp. C is a higher level programming language than lisp.
<aeth>
heh
<LdBeth>
nitrix: try to write a proper lisp interpreter then u would find out
<pjb>
Only C is botched, like all languages that have been inspired by lisp for 60 years.
<nitrix>
pjb, So mutating the parameter X would be observed only locally, by binding a new value to it, but mutating the value bound to the parameter X would have a bigger implications because Y uses that too?
<aeth>
pjb: See what I wrote in #scheme not very long ago to see how I disagree with you about C behing higher level than Lisp
<aeth>
*being
<pjb>
nitrix: yes.
<nitrix>
LdBeth, I'm asking these questions to write one myself, yes.
<oni-on-ion>
lisp isnt impeccable is it ?
<pjb>
aeth: we're talking about informal notions here. You can take all informal statements to #lispcafe.
nanoz has quit [Ping timeout: 252 seconds]
<nitrix>
pjb, what are those CL operators for my knowledge :) ?
<pjb>
aeth: I say C is higher level because of how it specifies pointers, memory, and foremost, bit manipulation. You must manipulate bits in C using integer operations (very abstractly). In CL we have bit operators.
<aeth>
nitrix: What's fun is that CL has 0-dimensional arrays. (make-array '() :initial-element 42)
<aeth>
nitrix: So if you wanted to modify some global integer in the simplest way you could just put it in a 0 dimensional array
<pjb>
What's sad, is that they couldn't map those arrays to scalar values.
<aeth>
Then you'd (setf (aref foo) 43) inside the function and get #0A43 outside
<nitrix>
aeth, I'm not especially interested by global anything as they tend to be treated differently.
<oni-on-ion>
there are more things "behind the scenes" happening with lisp. that is most people's intuitive understanding of what is "higher level" (like super-natural)
<aeth>
nitrix: You can compare the two items in this list: (list (let ((x (make-array '() :initial-element 42))) (let ((x x)) (setf x 43)) x) (let ((x (make-array '() :initial-element 42))) (let ((x x)) (setf (aref x) 43)) x))
<nitrix>
pjb: How would I rebind a new value to X, versus, mutating the value that's bound to X?
<oni-on-ion>
ugh
<pjb>
nitrix: you would need to implement the C pointer abstraction.
<LdBeth>
nitrix: then the book “interpreting lisp” has cover most aspects, please try read then ask questions
<oni-on-ion>
what is 'X' ?
<nitrix>
oni-on-ion, <nitrix> (define n 42) (define (foo x y) ...) (foo n n)
<pjb>
nitrix: in the case of symbols, you can use the name for special variables. defvar and defparameter declare special variables. You can also declare temporary special variables.
<aeth>
nitrix: The easiest way to get something like &foo where foo is an int is to put it in a 0D array as I said.
<aeth>
very roughly
<aeth>
you rarely find the need to do this in CL because CL has multiple return values
<aeth>
So you'd just do (values a b c) where in C you might mutate an input variable
<oni-on-ion>
nitrix, oh. well the name (symbol) is not the value which it points to.
<nitrix>
aeth, but that'd mean that CL uses pass-by-value where the values are sometimes pointers for specific types (like arrays) and you're exploiting that to obtain the pointer effect.
<pjb>
indeed.
<oni-on-ion>
are we teaching how to do C-stuff in lisp ? what if we dont need to do those things in lisp....?
<pjb>
We answer all questions, even silly ones.
<aeth>
nitrix: you could think of it as *always* passing in pointers, it's just that if it's a pointer to a constant value 42 that fits in a word including its type tag, it gets optimized away
<oni-on-ion>
true. i am very thankful for that personally.=)
<pjb>
nitrix: the problem is that as indicated in the /topic, Common Lisp is the #1=(programmable . #1#) programming language.
<pjb>
nitrix: so we can do any silly thing you want in CL.
<pjb>
nitrix: so probably it's not a good idea to ask this kind of questions.
<aeth>
oni-on-ion: I mean yesterday someone said that C++'s hello world was the ugliest so I implemented it in CL.
<aeth>
I solve all problems if they can be solved in < 1 hour :-p
<pjb>
nitrix: also notice how I said that C was a botched derivative of lisp (like most other current programming language).
<pjb>
nitrix: this means that you can do anything those languages can do, rather trivially in lisp.
<pjb>
nitrix: but this doesn't mean it's a good idea to do it.
<pjb>
If we've lived 60 years without pointers in lisp, there's a reason!
<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?
<oni-on-ion>
c was derived from lisp? wasnt it B ?
<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.
<nitrix>
Look at my cloak...
<pjb>
oni-on-ion: yes, it was. But C took the pass-by-value of lisp. :-)
<aeth>
pjb: eh, a while back someone who was working on a Prolog said that prolog isn't easily embeddable in Common Lisp
<aeth>
at least, not without some implementation extensions
<oni-on-ion>
pjb, ah, before this everything was by-ref ?
<pjb>
aeth: yes, that's why there are prolog interpreters in books for lisp newbies.
<nitrix>
pjb: My cloak literally says haskell developper ;)
<pjb>
aeth: cf. Norvig's PAIP.
<aeth>
pjb: the issue is usually about efficiency.
<aeth>
you can compile anything to any other Turing complete language (see: JavaScript)
<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.
<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!
<LdBeth>
nitrix: that’s even good, because I’ve looked tons of Haskell projects teaches how to write a lisp
<pjb>
C executables link with a 20 MB libc, which is about the same size as the libecl library.
<oni-on-ion>
pjb, did you see the second half after the question mark ?
<pjb>
So you can either use an image based system, and have your library "statically linked" or you can use ecl, and libecl.so.
<oni-on-ion>
lisp interpreter/runtime also links to that 20mb libc.
<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
<pjb>
oni-on-ion: well, the use of libc is only out of lazyness, to access the syscalls.
<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...
<pjb>
oni-on-ion: we could implement the syscall ABI in CL implementations and do entirely without libc.
<oni-on-ion>
the least amount of baggage is pure assembly of course, then next slimmest-to-system closest-to-metal is C.
<oni-on-ion>
pjb, ah? i see, thats cool =)
<pjb>
Which could be a good idea, actually. This would let us work on microcontrollers…
<oni-on-ion>
i seem robert strandh's (sp) paper on CLOS OS
<aeth>
pjb: You can only directly use syscalls as a stable interface in Linux.
<nitrix>
LdBeth: Choosing the semantics is the hard part. I want to better understand the choices behind CL and their implications.
<aeth>
You have to go through the (C?) OS APIs in macOS and Windows
<oni-on-ion>
i think linux abi has been stable for a while. windows 10 64bit ships with binary compat (WSL)
<pjb>
aeth: of course, this is work to maintain the syscall ABI on all target platforms. Hence we defer to libc maintainers…
<oni-on-ion>
so its like living in a house thats owned by a landlord ?
<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
<aeth>
so your implementation could break on any random Tuesday
<oni-on-ion>
aeth, ahh i think i see what you mean
<LdBeth>
nitrix: there’s not much semantic difference between CL and Scheme, except for continuation part
<LdBeth>
And macro
<oni-on-ion>
scheme is kind of pretty
<aeth>
LdBeth: continuations and tail recursion. That's like 95% of the runtime difference
pankajgodbole has joined #lisp
<oni-on-ion>
and proper keyword syntax. =P
<nitrix>
Alright. Thanks for the help. Tiny progress was made but it quickly turned into chaos. I'll give it a try another day.
<nitrix>
Have a good evening. Cheers :)
<LdBeth>
aeth: I guess having continuation implemented in CL won’t violate the standard
<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
<oni-on-ion>
we like any chance to share what we like
<LdBeth>
Good night
<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
<oni-on-ion>
aeth, nil/#f
<aeth>
oni-on-ion: That's easy, just make #f into :false (or some other symbol)
<pjb>
LdBeth: only it's very difficult to have both continunations and block/return catch/throw.
<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.
<pjb>
and indeed, there's the problem of () vs. nil in scheme.
zmt00 has joined #lisp
<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
<aeth>
nil vs. #f isn't a problem, trust me on that one :-)
<LdBeth>
pjb: I believe Chez has accomplished that by means of lexical continuation and dynamic continuation
<aeth>
It is, literally, 95% about continuations and tail recursion
<aeth>
and most of that 95% is continuations
<LdBeth>
*scope
<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.
<pjb>
It's not simply a lexical matter.
<oni-on-ion>
guile does elisp and scheme (r7?)
<oni-on-ion>
( also an older version of javascript)
<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 '()
<oni-on-ion>
my conclusion is that the true ultimate computer language is simply binary and ascii. everything else is a subset
<LdBeth>
What’s the point of call scheme in CL?
<aeth>
And, if you really wanted to, calling Scheme from CL could just always turn #f into nil
<oni-on-ion>
Thought Experiment Hour
sauvin has joined #lisp
<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
<oni-on-ion>
we are getting closer. BEAM vm, JVM, CLR, GraalVM, WASM , LLVM, ...
<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)
<oni-on-ion>
hmm chez is quite fast aeth
<aeth>
I await the comparative benchmarks
<aeth>
Well, actually, I can't really wait on them, since what everyone's waiting on here is my code.
<LdBeth>
I mean CL and Scheme is still close enough to interpolate with only the help of macro
<aeth>
except for continuations and tail recursion...
<aeth>
:-)
gingerale has quit [Quit: Don't worry, I'll return]
<aeth>
Am I the only one who has tried this?
oni-on-ion has quit [Disconnected by services]
<LdBeth>
so, what continuation could do that regular control flow can’t achieve?
oni-on-ion has joined #lisp
<LdBeth>
Turing completeness
vibs29 has quit [Ping timeout: 245 seconds]
<White_Flame>
none, really. continuations are an abstraction for flow control
<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.
vibs29 has joined #lisp
<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.
<oni-on-ion>
'from a foreign language' ? do you mean using a foreign language to access, or accessing the library *in* a foreign lang?
<pjb>
oni-on-ion: both.
<oni-on-ion>
right
<oni-on-ion>
ok
<pjb>
You can link thru FFI, or you can compile the foreign source.
<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
<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.
<pjb>
So perhaps we should better work on Hemlock (or climacs)…
<oni-on-ion>
wait wait... C->CL in emacs ?? =)
<pjb>
No the opposite.
<oni-on-ion>
i heard Second Climacs is going well
<pjb>
I would compile GNU emacs using the C->CL to run GNU emacs in Cl
<oni-on-ion>
ok. just retyping what you toped
<oni-on-ion>
ohh
<oni-on-ion>
bunch of rustaceans are busy converting all that precious historical C
<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.
<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
<LdBeth>
GG
jack_rabbit has quit [Read error: Connection reset by peer]
campy_fellow has quit [Ping timeout: 252 seconds]
ggole has joined #lisp
campy_fellow has joined #lisp
<loke`>
oni-on-ion: Packages
<oni-on-ion>
imagine CL without asdf.... i can't even without quicklisp
<oni-on-ion>
well i remember trying out CL before quicklisp and it was not fun
<oni-on-ion>
not just CL will need asdf; but uiop, bordeaux-threads, grey-streams, and so on.
<LdBeth>
You can use defsystem
<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.
<oni-on-ion>
pjb, hmm, true! that sounds like its close to how nice smalltalk felt with ChangeSets
jprajzne has joined #lisp
<oni-on-ion>
the convenience of luxury has a dark side
<pjb>
Yep.
dale has quit [Quit: dale]
campy_fellow has quit [Read error: Connection reset by peer]
<oni-on-ion>
i think ive still got some of the webserver code that i used defsystem with, around 2011
campy_fellow has joined #lisp
<oni-on-ion>
im reflecting on whether these conveniences are perverting the pristine shimmering purity of CL
Necktwi has quit [Ping timeout: 258 seconds]
<no-defun-allowed>
just cause you can write your own loader doesn't mean you should
<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
JohnMS_WORK has joined #lisp
oni-on-ion has quit [Ping timeout: 268 seconds]
<aeth>
Real Common Lisp programmers use makefiles!
<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.
asarch has quit [Quit: Leaving]
<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
<stylewarning>
“Shimmering purity” “CL”
oni-on-ion has joined #lisp
<stylewarning>
There’s a famous quote about Common Lisp:
<no-defun-allowed>
ball👏of👏mud👏
<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."
<stylewarning>
Sorry I misquoted. You’re supposed to transpose “paradigms” and “functions”.
Nilby has joined #lisp
easye has joined #lisp
<oni-on-ion>
is that some pewdiepie
<oni-on-ion>
whats a cribhouse
<oni-on-ion>
traphouse* ?
<no-defun-allowed>
a brothel
<oni-on-ion>
ahh. good quote though. but it can be applied to many things like JS
<no-defun-allowed>
CL executes them well though
<oni-on-ion>
sher will make you feel like the king of the world
<Nilby>
Indeed, I spent part of today rifling through the pockets of code in other languages, just to "borrow" them for CL.
<oni-on-ion>
you may have found a new species if CL didnt already have it
<Nilby>
In this I pilferd Clojure's group-by, which was probably implemented in Lisp before Lisp was.
<Nilby>
At least it's as old as the idea of the alist.
<oni-on-ion>
ohh. makes me think of elisp's dash library - which is great
<oni-on-ion>
and i think borrowing is great
beach has quit [Disconnected by services]
beach has joined #lisp
karlosz has joined #lisp
<shka_>
not borrowing, assimilating
<shka_>
resistance is futile
<oni-on-ion>
not returning! take digital copies into infinity !
gxt has quit [Ping timeout: 258 seconds]
<oni-on-ion>
no rewind!
<no-defun-allowed>
well we don't intend to give them back so is it borrowing? also, they still have it too
<shka_>
anyway, assimilating foreign ideas in programming is arguably more powerful then coming up with your own
<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
<oni-on-ion>
digital copies, they keep the originals as well
<shka_>
no-defun-allowed: well, sometimes results is greater then sum of it's parts
<splittist>
good morning
schweers has joined #lisp
<beach>
Hello splittist.
edgar-rft has quit [Quit: Leaving]
<oni-on-ion>
shka_, i think that may be related to the definition of sum ?
scymtym has joined #lisp
_whitelogger has joined #lisp
another-user has joined #lisp
zcid has quit [Ping timeout: 248 seconds]
oni-on-ion has quit [Remote host closed the connection]
wigust- has joined #lisp
oni-on-ion has joined #lisp
wigust has quit [Ping timeout: 245 seconds]
oni-on-ion has quit [Remote host closed the connection]
libre-man has quit [Ping timeout: 246 seconds]
karlosz has quit [Ping timeout: 246 seconds]
Arcaelyx has quit [Ping timeout: 258 seconds]
karlosz has joined #lisp
Snowbear has joined #lisp
hhdave has joined #lisp
lnostdal has joined #lisp
Snowbear has quit []
libre-man has joined #lisp
edgar-rft has joined #lisp
SaganMan has joined #lisp
<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))
techquila has quit [Ping timeout: 248 seconds]
<no-defun-allowed>
(signed-byte 31) surely
techquila has joined #lisp
v88m has quit [Remote host closed the connection]
libertyprime has quit [Quit: leaving]
v88m has joined #lisp
Folkol_ has joined #lisp
Folkol_ has quit [Read error: Connection reset by peer]
<aeth>
e.g. (deftype uint32 () `(unsigned-byte 32))
<saturn2>
awesome
<aeth>
that was motivated by rendering code, not header files, though
<aeth>
if anyone writes header files in Lisp they're doing it wrong...
<loke`>
aeth: isn't your canonical package.lisp that most systems have pretty much that?
m00natic has joined #lisp
svillemot_ is now known as svillemot
orivej has joined #lisp
<aeth>
loke`: it has no duplicated information, and it's usually per-directory
zcid has joined #lisp
<aeth>
I guess a hypothetical foo.h.lisp would be the worst of both package.lisp and package-at-the-top styles
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
<loke`>
aeth: It duplicates the names of the functions.
<loke`>
(defun foo :exported (a) (1+ a))
<loke`>
that would not duplicate information
<loke`>
Of course, this is Lisp and we can do this
Necktwi has joined #lisp
sz0_ has joined #lisp
fivo has joined #lisp
dddddd has joined #lisp
<aeth>
That wouldn't work because we export symbols, not functions. Well, it would work, just with some unexpected edge cases.
asdf_asdf_asdf has joined #lisp
dddddd has quit [Ping timeout: 258 seconds]
<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.
<asdf_asdf_asdf>
(define-alien-type HDC (* void))
dddddd has joined #lisp
kajo has joined #lisp
Folkol_ has joined #lisp
varjag has joined #lisp
asdf_asdf_asdf has left #lisp [#lisp]
asdf_asdf_asdf has joined #lisp
SaganMan has quit [Ping timeout: 258 seconds]
<shka_>
hello all
<schweers>
asdf_asdf_asdf: maybe just (*)? anyway, is there a reason you’re using sb-alien instead of CFFI? or some ohter portablility layer?
<shka_>
https://github.com/numcl/numcl this got my interest, it looks pretty good on the surface, what do you guy thinks?
<beach>
Hello shka_.
<shka_>
and gals, obviously
<shka_>
beach: good day
<Nilby>
"void *" in sb-alien is: (* t), but it's better use cffi (:pointer :void)
<schweers>
Or even just :pointer
Sabex has joined #lisp
<asdf_asdf_asdf>
schweers, Nilby. Very thanks for help. With (* t) - works.
ebrasca has joined #lisp
<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.
Sabex has quit [Remote host closed the connection]
<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…
heisig has joined #lisp
<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.
lnostdal has quit [Read error: Connection reset by peer]
Lord_of_Life has quit [Ping timeout: 268 seconds]
v88m has quit [Read error: Connection reset by peer]
v88m has joined #lisp
Lord_of_Life has joined #lisp
v88m has quit [Read error: Connection reset by peer]
v88m has joined #lisp
<schweers>
It seems to choke on some lparallel function. weird.
v88m has quit [Read error: Connection reset by peer]
v88m has joined #lisp
schweers has quit [Read error: Connection reset by peer]
schweers has joined #lisp
v88m has quit [Read error: Connection reset by peer]
v88m has joined #lisp
Inline has quit [Quit: Leaving]
orivej has quit [Ping timeout: 245 seconds]
JohnMS has joined #lisp
JohnMS has quit [Client Quit]
JohnMS_WORK has quit [Ping timeout: 244 seconds]
gareppa has joined #lisp
anewuser has joined #lisp
schweers has quit [Remote host closed the connection]
pierpal has quit [Remote host closed the connection]
schweers has joined #lisp
Inline has joined #lisp
campy_fellow has quit [Ping timeout: 246 seconds]
campy_fellow has joined #lisp
Bike has joined #lisp
campy_fellow has quit [Read error: Connection reset by peer]
campy_fellow has joined #lisp
atgreen has joined #lisp
atgreen has quit [Read error: Connection reset by peer]
<pjb>
but in sbcl alien, which can be found there -> #sbcl
<Nilby>
sb-alien::alien-lambda
Jesin has quit [Quit: Leaving]
<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.
<Nilby>
or rather sb-alien:define-alien-callback, but I prefer cffi:defcallback
<asdf_asdf_asdf>
OK, but where is it in manual SBCL?
<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
<Nilby>
It's not. I read it from SBCL & CFFI source.
<Bike>
the sbcl manual has a huge section on the alien interface.
<Bike>
i even linked to the middle of it already
lumm has joined #lisp
_ark_ has quit [Ping timeout: 250 seconds]
<jfe>
hi all
<oni-on-ion>
hello
<asdf_asdf_asdf>
jfe, hi.
<jkordani>
minion: memo for schweers did you figure out what was going on with your code coverage issue?
<minion>
yes, i figure out what was going on with my code coverage issue
<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?
<sjl_>
jfe: what is an slist?
hhdave has quit [Quit: hhdave]
<jfe>
symbolic list -- sorry, i was trying to be concise :)
<makomo>
symbolic list?
<sjl_>
next question: what is a symbolic list?
<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.
orivej has quit [Ping timeout: 258 seconds]
<makomo>
unless you were thinking of something else
<sjl_>
but the rel isn't there at macroexpansion time. all the macro actually gets is what you give it: the symbol REL
<jfe>
exactly. is there a trick for dealing with this?
<jfe>
does predicate-bind also need to be a macro?
<asdf_asdf_asdf>
jfe, what's your issue is?
<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.
<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.
<Bike>
the value of rel doesn't even exist at macroexpansion time.
<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.
<sjl_>
2. A macro that's a thin layer on top of that function, so you don't have to manually quote that list
maxxcan has joined #lisp
maxxcan has quit [Remote host closed the connection]
<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
<jfe>
hmm okay i'll chew on that for a bit. thanks.
ggole has quit [Quit: Leaving]
<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
<sjl_>
e.g. I'd imagine the macro would look like (defmacro rel-select (rA query) `(perform-rel-select ,rA ',query))
<jfe>
i need to somehow convert the query to a function object
bexx has joined #lisp
<makomo>
what's an example of a query?
<jfe>
a query might look like '(< 3 :foo). then i convert this expression to '(lambda (tuple) < 3 (nth <'foo' column number> tuple))
<selwyn>
xach remarks that the sbcl compiler is 'pretty slow'. is that true today?
m00natic has quit [Remote host closed the connection]
<Xach>
selwyn: yes.
cosimone has quit [Ping timeout: 248 seconds]
<makomo>
are there any utility libraries for working with hierarchical alists/plists?
<makomo>
hierarchical, i.e. nested
<makomo>
stuff like querying the plist (:hello (:there 123 :world 456)) with a "nested indicator" '(:hello :world), or merging the nested plist with another nested plist, adding a key if it doesn't exist (recursively, just like mkdir -p creates directories), etc. etc.
<makomo>
seems like quite useful functionality for macros that have non-trivial syntax based on nested plists
cosimone has joined #lisp
<makomo>
or for simple nested dictionaries backed by plists
jxy has quit [Quit: leaving]
<Xach>
selwyn: whether it's "too slow" or not is of course a matter of context.
TMA has quit [Ping timeout: 255 seconds]
eddof13 has joined #lisp
TMA has joined #lisp
gxt has joined #lisp
Jesin has quit [Quit: Leaving]
lumm has quit [Quit: lumm]
lumm has joined #lisp
cosimone has quit [Ping timeout: 252 seconds]
cosimone has joined #lisp
Jesin has joined #lisp
scymtym has quit [Remote host closed the connection]
lumm has quit [Quit: lumm]
lumm has joined #lisp
fivo has quit [Quit: WeeChat 1.9.1]
lumm has quit [Remote host closed the connection]
karlosz has quit [Quit: karlosz]
<pjb>
Actually, sbcl compiler is one of the fastest CL compiler there is, since it's compiled using sbcl compiler itself, which produces one of the fastest CL native code.
<pjb>
It is fast, only it takes more time to do the optimizations.
vlatkoB has quit [Remote host closed the connection]
gxt has quit [Ping timeout: 246 seconds]
Lycurgus has quit [Quit: Exeunt]
maxxcan has joined #lisp
maxxcan has quit [Client Quit]
notzmv has quit [Ping timeout: 246 seconds]
actuallybatman has joined #lisp
<pfdietz>
Building sbcl from source using sbcl takes about 1:35 on my desktop. Pretty fast.
eddof13 has quit [Quit: eddof13]
<aeth>
People who call compilation of something not in C++ slow don't compile enough C++
<oni-on-ion>
or julia or haskell.
<grewal>
aeth: You say that like it's a bad thing
<oni-on-ion>
pfdietz, nice! i timed --fancy just now and its 284sec
<oni-on-ion>
which looks to be about 4min
sz0_ has quit [Quit: Connection closed for inactivity]
kajo has joined #lisp
<asdf_asdf_asdf>
Hi. How define body of routine? After defined routine I must defined body this routine? How it do? Thanks.
<asdf_asdf_asdf>
(define-alien-routine x (y int))
<asdf_asdf_asdf>
(define-body-routine x (+ y 2))
<asdf_asdf_asdf>
For example, above.
<Xach>
asdf_asdf_asdf: there is no body. it is declaring an interface to an existing foreign function, so it is for specifying the arguments and return type.
<asdf_asdf_asdf>
Xach, OK; so I should use with-alien, to declare body routine?
parjanya has quit [Ping timeout: 258 seconds]
<Xach>
asdf_asdf_asdf: what are you trying to do?
<asdf_asdf_asdf>
Assign variables values from arguments routine.
<Xach>
asdf_asdf_asdf: are you trying to use and interact with C data and functions?
<asdf_asdf_asdf>
Yes.
warweasle has quit [Quit: rcirc on GNU Emacs 24.4.1]
<Xach>
asdf_asdf_asdf: which ones?
<Xach>
asdf_asdf_asdf: scratch that - no matter what the answer is, i cannot help - but maybe someone else can.
gxt has joined #lisp
eddof13 has joined #lisp
troydm has quit [Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset]
defunkydrummer has joined #lisp
jxy has joined #lisp
gxt has quit [Ping timeout: 248 seconds]
gxt has joined #lisp
<aeth>
asdf_asdf_asdf: Usually you want to find a JSON version of the API that you can parse rather than doing it manually yourself... afaik.
<aeth>
If it's a common "I have to interface with this" library, then JSON (or XML) versions exist for exactly this purpose, sometimes officially.
<Bike>
i'm not sure a json version of winapi is usual
<aeth>
It would be incredibly amusing (and not *entirely* surprising, since Microsoft has tried like 20 different APIs) if you could interact with Windows directly via XML.
zooey has quit [Quit: quit]
amerlyq has quit [Quit: amerlyq]
hiroaki has joined #lisp
mindCrime_ has quit [Ping timeout: 255 seconds]
<defunkydrummer>
asdf_asdf_asdf: there are already winapi bindings out there
<defunkydrummer>
minion: memo to asdf_asdf_asdf: there are already Win32 API bindings out there, see https://github.com/Zulu-Inuoe/win32 for an example.
<minion>
Remembered. I'll tell asdf_asdf_asdf when he/she/it next speaks.
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
<defunkydrummer>
minion: memo to asdf_asdf_asdf: also this guy has several bindings to various Win32 APIs: https://github.com/fjames86
<minion>
Remembered. I'll tell asdf_asdf_asdf when he/she/it next speaks.
zotan has quit [Ping timeout: 258 seconds]
zotan has joined #lisp
ebrasca has quit [Read error: Connection reset by peer]
ebrasca has joined #lisp
notzmv has joined #lisp
notzmv is now known as Guest32627
zooey has joined #lisp
ebrasca has quit [Remote host closed the connection]
mooch has joined #lisp
Guest32627 has left #lisp [#lisp]
notzmv has joined #lisp
lumm has quit [Remote host closed the connection]
DXH30 has joined #lisp
defunkydrummer has quit [Remote host closed the connection]