gabiruh has quit [Quit: ZNC - 1.6.0 - http://znc.in]
iovec has quit [Quit: Connection closed for inactivity]
quazimodo has joined #lisp
ravenousmoose has joined #lisp
ravenousmoose has quit [Ping timeout: 245 seconds]
karlosz has joined #lisp
EvW has quit [Ping timeout: 250 seconds]
Oladon1 has joined #lisp
Oladon has quit [Ping timeout: 240 seconds]
jprajzne has quit [Quit: jprajzne]
bitmapper has quit [Ping timeout: 240 seconds]
jprajzne has joined #lisp
cods has quit [Ping timeout: 245 seconds]
longshi has quit [Ping timeout: 265 seconds]
semz has quit [Ping timeout: 276 seconds]
orivej has quit [Ping timeout: 268 seconds]
libertyprime has joined #lisp
igemnace has joined #lisp
jprajzne has quit [Quit: jprajzne]
jprajzne has joined #lisp
semz has joined #lisp
semz has quit [Changing host]
semz has joined #lisp
wxie has joined #lisp
jprajzne has quit [Quit: jprajzne]
jprajzne has joined #lisp
lucasb has quit [Quit: Connection closed for inactivity]
igemnace has quit [Ping timeout: 240 seconds]
jprajzne has quit [Quit: jprajzne]
jprajzne has joined #lisp
buffergn0me has joined #lisp
dale has joined #lisp
igemnace has joined #lisp
jprajzne has quit [Quit: jprajzne]
jprajzne has joined #lisp
torbo has joined #lisp
jprajzne has quit [Client Quit]
jprajzne has joined #lisp
akoana has left #lisp ["Leaving"]
libertyprime has quit [Ping timeout: 265 seconds]
ithos has joined #lisp
wxie has quit [Remote host closed the connection]
ebzzry has quit [Ping timeout: 276 seconds]
clothespin has joined #lisp
libertyprime has joined #lisp
_whitelogger has joined #lisp
cdddr has joined #lisp
quazimodo has quit [Ping timeout: 240 seconds]
jprajzne has quit [Quit: jprajzne]
<remexre>
with cffi, is there a way to "late-bind" which library name is used? e.g. glfw can load as libglfw or libglfw3, but it appears that it gets "frozen" to whatever name was actually found
<remexre>
so if my build machine uses libglfw.so.3.1, and my target machine uses libglfw.so.3.2, the binary fails to run
<remexre>
(I guess that's not directly related to libglfw vs libglfw3... /shrug)
jprajzne has joined #lisp
asdf_asdf_asdf has quit [Quit: asdf_asdf_asdf]
<LdBeth>
seems the only thing you do is recompile the project
<LdBeth>
with the library symlinks to appripate locations
raghavgururajan has joined #lisp
vms14 has quit [Remote host closed the connection]
buffergn0me has left #lisp ["ERC (IRC client for Emacs 26.2)"]
<LdBeth>
remexre: you may do that by hacking directly with the lower level FFI provided by the implementation
<remexre>
er, what I want is a binary that will work with any libglfw.so
<remexre>
like if I linked C w/ -lglfw, it'd link to libglfw.so and the symlinks would resolve to .so.3.1 or .so.3.2
<remexre>
that's the behavior I wnat
Necktwi has joined #lisp
<LdBeth>
Well this is not possible for regular executable binary compiled from languages like C, you know ;0
<LdBeth>
So it is not a required feature for distributing your app as other Unix softwares
leb has quit []
<remexre>
huh?
<remexre>
er, my point is that there's a slight behavioral difference between gcc -l and cffi; I don't think there's any fundamental difference in capabilities
<LdBeth>
then you just need to redefine the cffi library to use only libglfw.so for example, and expect the target machine does have the symlink setup
<remexre>
once I compile a binary, it /doesn't/ use the symlink
<remexre>
I'm trying to make it use the symlink
<remexre>
instead, it hardcodes the full path
<remexre>
er, the full filename, I think; I believe it still searches the full LD_LIBRARY_PATH
<saturn2>
are you saving the image as an executable?
<remexre>
yeah, with asdf:image-op
<saturn2>
in that case, there may be runtime state created by .so.3.1 that isn't compatible with .so.3.2
<LdBeth>
ah, right, you have to rerun (cffi:use-foreign-library ) at some time if you save the image
<remexre>
is there any way to pinky-promise to cffi that there isn't? :P
<saturn2>
unload and reload the library
cdddr has quit [Quit: leaving]
<remexre>
would I be able to just toss the cffi:use-foreign-library at the top of my :entry-point ?
<beach>
I wonder whether some of the people who insist on using foreign code are converted Pythonista who therefore think that calling C code is the only way to get good performance from their Common Lisp code.
enrioog has joined #lisp
<Josh_2>
mornin
<beach>
Hello Josh_2.
zdm has quit [Quit: nil]
enrio has quit [Ping timeout: 268 seconds]
<remexre>
beach: I mean, how else am I gonna get at GLFW / OpenGL
<remexre>
like, I'd love it if I had no FFI in my life
<remexre>
huh, looks like mezzano has opengl support via virgl
<remexre>
probably can't deliver a game as a VM image though :P
<beach>
Oh, wait, it's the prisoner's dilemma all over again. If everyone who needs a library that exists only as foreign code instead wrote an equivalent in Common Lisp, then everybody would benefit from everybody's code. But using foreign code is faster for each individual, so, like the prisoners, each individual chooses what benefits him/her. The result is that everybody suffers.
<Josh_2>
Perhaps people wouldn't know how to write that libray in CL
<remexre>
beach: OpenGL requires interfacing with the hardware directly, in ways not documented by most vendors
<beach>
Josh_2: That can be learned. It's part of the work.
<beach>
remexre: Then I would stay very, very far away from it.
<remexre>
beach: how else do I do accelerated 3d graphics...
<remexre>
like sure, CL can be as fast as C; C isn't fast enough by a few orders of magnitude
salinasce has quit [Ping timeout: 246 seconds]
<beach>
I have no answer for you. Personally, I would then do something other than accelerated 3d graphics.
<remexre>
Then I think we're at an impasse...
<beach>
remexre: My observation was not about you. It was about all the suffering I see here in #lisp by people using foreign code.
<remexre>
ah, fair
<Josh_2>
Sometimes you just don't have time to reimplement the library in CL
<beach>
Josh_2: You wouldn't always have to if each person took one chunk of the work.
<Josh_2>
I suppose
<Josh_2>
but sometimes knowledge is very specific, and requires a lot of investment
<Josh_2>
not everyone in our small community has time for such an investment
<beach>
But, from my analysis, I can see why it is not going to happen.
<aeth>
beach, remexre: Technically speaking, cl-opengl is mandatory. The rest of the stack (e.g. glfw or sdl), however, is not, but it would require a lot of work to write directly to WinAPI, xlib, etc., for all of the windowing code related to a 3D application.
<aeth>
(Okay, you could use something like cl-vulkan instead of cl-opengl, but you do need to use a graphics API because it's at the driver level... i.e. it's what the hardware speaks)
<remexre>
aeth: I mean, I've heard stories whispered in huddled corners of writing directly to the memory-mapped region of the GPU
<remexre>
so in theory (stretching the bounds of plausibility), you could reimplement all the libGL.so's in CL
<aeth>
remexre: Vulkan would be more possible because it does less
<remexre>
yeah
prite has joined #lisp
<aeth>
But you'd still be interfacing with a C API, just this time the Linux kernel's
<aeth>
Unless you used Mezzano
<remexre>
hm
<remexre>
can one call mmap without a foreign call?
<aeth>
That is probably implementation-specific
<remexre>
yeah, e.g. abcl wouldn't have it
<aeth>
And technically speaking, an implementation could build in OpenGL or Vulkan functionality as well as SDL-like/GLFW-like functionality
<aeth>
Shifts the burden of where the foreign code is
<remexre>
fair, though I feel like there's a difference between implementing GLFW bindings in the implementation and reimplementing a GLFW-like on top of "plain syscalls"
<saturn2>
mmap is a system call, not a foreign call
<saturn2>
your implementation is definitely already doing lots of system calls
<remexre>
Sure, but mmap() is a C function in libc, and afaik there's not a nice library for doing "raw syscalls," so in practice you're gonna be calling the C one
shifty has joined #lisp
<beach>
remexre: Oh, but that is an excellent Common Lisp project.
<saturn2>
you could make a library for syscalls pretty easily
<beach>
remexre: In fact, I started such a project, and it would be great to have an implementation-independent way of making Unix system calls.
<beach>
remexre: Such a project could be done in one syscall a day.
<saturn2>
i've used sbcl's sb-unix::int-syscall and just looked up the syscall number manually
<remexre>
oh, huh
<saturn2>
but having a library would be nicer, obviously
<aeth>
remexre: In SBCL, you should be able to do raw syscalls without using C because Linux has a stable ABI and SBCL allows you to do "inline asm" (not really "inline" because that's not how Lisp works, but the phrase is from other high level languages).
<aeth>
But that's just SBCL on Linux.
<saturn2>
you don't need asm, the function is already there
<aeth>
For Windows and macOS, the syscalls are an internal interface and you're expected to use the C libraries.
<remexre>
aeth: huh, TIL
<aeth>
saturn2: oh, even better
<remexre>
yeah, it shocked me when a normal windows update actually changed the syscall numbers, breaking an asm program I was writing
<beach>
Another thing I would stay very, very far away from then.
<saturn2>
don't use closed source OSes :)
<aeth>
remexre: probably not a normal one... Windows 10 is supposed to be the "last" Windows and they have fairly major updates every 6 months or so, not unlike a distro like Ubuntu or Fedora
<aeth>
(in fact, probably copied from them)
<remexre>
aeth: iirc this was an unnamed update, though it might've been one of the 6mo ones
<remexre>
idk, I'm kinda trying to go the Oberon route and build my own lang+OS; rn I'm going with s-exprs and image-based, but strongly typed and with hot code loading only at the "thread" level
<no-defun-allowed>
Just to check, is that statically typed (like Haskell) or strongly typed (like Common Lisp)?
<remexre>
er, statically within "threads"; dynamically+strongly in IPC
<remexre>
with a dependent type system; right now just MLTT with inductive datatypes
<remexre>
probably going to have CL-style macros, though I'm not implementing this rn; it looks like most of what I'd want macros for, I could get with some sort of &block (like Ruby blocks)
reggie_ has quit [Ping timeout: 240 seconds]
reggie_ has joined #lisp
Lycurgus has joined #lisp
toorevitimirp has quit [Ping timeout: 265 seconds]
_whitelogger has joined #lisp
torbo has quit [Remote host closed the connection]
jprajzne has quit [Quit: jprajzne]
jprajzne has joined #lisp
notzmv has quit [Read error: Connection reset by peer]
jprajzne has quit [Quit: jprajzne]
notzmv has joined #lisp
ggole has joined #lisp
jprajzne has joined #lisp
Lycurgus has quit [Quit: Exeunt]
libertyp1ime has joined #lisp
notzmv has quit [Remote host closed the connection]
libertyp1ime has quit [Client Quit]
zdm has joined #lisp
libertyprime has quit [Remote host closed the connection]
jgodbout has quit [Remote host closed the connection]
jprajzne has quit [Quit: jprajzne]
jprajzne has joined #lisp
jprajzne has quit [Quit: jprajzne]
refusenick has joined #lisp
jprajzne has joined #lisp
jonatack has quit [Ping timeout: 250 seconds]
<refusenick>
How do I set the axes and labels in wxplot2d and wxplot3d to be white? I'm running Imaxima in Emacs with a dark background, and the default black labels look bad unless I go to a light background.
<Ober>
but Lisp means CL, and the only legit variant today IS sbcl no?
<p_l>
`no
<beach>
*sigh*
<p_l>
there's no "only legit variant"
<p_l>
we have a lot of useful, compatible implementations
<p_l>
where possible, we try to recommend implementation-independent approaches, because they lead to healthier community
<p_l>
(and, IMO, better code)
fanta1 has quit [Quit: fanta1]
salinasc has joined #lisp
<Ober>
oh right, I forgot GCL
salinasce has quit [Remote host closed the connection]
<p_l>
...
<p_l>
you *must* be trolling
<beach>
I think that is the case.
<g_o>
well, thanks anyway :)
<beach>
p_l: And you took the bait.
<Ober>
nope. No more than the idea that Lisp means CL
EvW has quit [Ping timeout: 250 seconds]
<Ober>
just given the history here, almost always sbcl is recommended as the implementation, rarely an alternative
<p_l>
beach: I figured that at low traffic explaining that might be good, and assumed good faith
* beach
adds g_o as another data point to the statistics of suffering that was mentioned some 10 hours ago.
<p_l>
Ober: on Linux/amd64 platform, SBCL would indeed be my "default recommendations"
<p_l>
but not always
manualcrank has joined #lisp
<p_l>
SBCL has significant list of cons (pun intended), including long compilation times and being pretty memory hungry (it generates fast but big on memory code)
<Ober>
sure, I should have rephrased it, but endless effort fighting issues on other implementations tends to lead to the general advice to new folks to use sbcl outright.
<p_l>
Ober: if the new folks are on Mac or Windows, I generally recommend CCL
<Ober>
sbcl on mac is very good these days. imho
<p_l>
on some platforms I would actually recommend ECL, but not many people can claim to be "new" on those platforms
<p_l>
Ober: I'm also still pretty sure it's slower in following yet-another-brammage from Apple than CCL
<p_l>
(and it took months to get CCL running on Mojave, iirc)
<selwyn>
can you give an example of one of these platforms where you would recommend ecl?
<Ober>
as fare says adsf has a long tail of implementations supported. but I would not be recommending any of them.
<p_l>
selwyn: z/OS (with USS/OMVS), random platforms that accept mostly ANSI/C99 code with bits of posixish APIs, etc.
<p_l>
Ober: letting ossification creep in isn't good
<p_l>
in case of ASDF, the long-tail stretched back to platforms that didn't see serious updates since 1994
<p_l>
SBCL, CCL, CLISP, ECL, LW, ACL all have current updates
<p_l>
that's the real difference
<p_l>
and there's small chance Corman might creep back, though updating it for 64bits would be a challenge afaik
augfab has joined #lisp
toorevitimirp has quit [Remote host closed the connection]
retropikzel has joined #lisp
<p_l>
I personally believe that keeping to cross-platform by default is going to be good for community
<White_Flame>
plus there's Clasp
<White_Flame>
which either is or should be getting to general usage for C++ integrated scenarios
g_o has left #lisp ["No boundaries on the net!"]
bkhl has left #lisp ["Leaving"]
<p_l>
At the moment I'd be just happy to maybe use it as CL's equivalent of SIP, since I'm really not in the mood to write C++ to interrogate Clang about vtable layouts
<p_l>
(and proper exception handling is something that actually gave me waking nightmares when I tried to implement it in ~2010)
<p_l>
and as my recent experience with CommonQT shows, we need to update tooling because Qt4 is actually unbuildable/unrunnable in some cases
clothespin has quit [Ping timeout: 250 seconds]
<selwyn>
i wonder if having potentially large c++ libraries available in CL (via clasp without C wrappers) would significantly affect the lisp community
<beach>
What is your own opinion?
<p_l>
selwyn: unfortunately C++ is used heavily enough in some cases that it is unavoidable in *current* state of the world
<p_l>
especially since the ways to actually have multi-language interoperability are reviled by people outside of MS
<p_l>
And I want CL used more in general, not just in rather closed off pockets that can deal with just reimplementing around C++
ralt has quit [Quit: Connection closed for inactivity]
papachan has quit [Quit: Leaving]
frgo has joined #lisp
<selwyn>
beach: there are some fields such as professional game development in which one cannot do without making use of large existing c++ libraries. having these libraries available in lisp all of a sudden certainly makes the space of lisp applications much bigger. having said that, i doubt that having a lisp game published would have significant positive effect on, say, the lisp library ecosystem
<selwyn>
but perhaps there are some other fields in which one would see a positive effect
frgo has quit []
longshi has quit [Ping timeout: 276 seconds]
<p_l>
certain ML areas are full of C++, sometimes so bad C++ you can barely use it as C++ (I'm looking at tensorflow specifically)
shka_ has joined #lisp
<beach>
selwyn: I see, thanks.
frgo has joined #lisp
<beach>
p_l: I understand that there is a huge amount of C++ out there. I was wondering about selwyn's own thoughts about whether the availability of that software to Common Lisp programmers would influence the Common Lisp community.
<p_l>
beach: figured I'd answer selwyn's musings while they worked over their own answer
<p_l>
IMO it's *not* trivial topic
<beach>
Ah, OK. Got it.
<beach>
selwyn: There is also the possibility of a negative impact. If large amounts of bad and unsafe C++ code is available, it might discourage the use of safe, native Common Lisp code.
<beach>
I don't have an opinion either way myself.
<selwyn>
beach: good point. i would prefer not to touch c++, but i do find lisp and c++ integration interesting in its own right due to the myriad of issues that have to be overcome
igemnace has joined #lisp
duuqnd has joined #lisp
prite has joined #lisp
Grauwolf has quit [Quit: WeeChat 2.5]
rippa has joined #lisp
<p_l>
it's easy topic on Windows, but that's because MS heavily invested in making all APIs accessible from anything you want
fanta1 has joined #lisp
nowhere_man has quit [Ping timeout: 276 seconds]
frgo has quit []
gareppa has joined #lisp
gareppa has quit [Client Quit]
frgo has joined #lisp
Grauwolf has joined #lisp
Grauwolf has quit [Changing host]
Grauwolf has joined #lisp
flak has joined #lisp
lucasb has joined #lisp
rippa has quit [Ping timeout: 268 seconds]
fanta1 has quit [Quit: fanta1]
makomo has quit [Ping timeout: 265 seconds]
reggie_ has quit [Ping timeout: 240 seconds]
<fiddlerwoaroof>
/window/zoom
lxbarbosa has quit [Read error: Connection reset by peer]
lxbarbosa has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
toorevitimirp has joined #lisp
fanta1 has joined #lisp
techquila has joined #lisp
toorevitimirp has quit [Client Quit]
mindthelion has quit [Ping timeout: 240 seconds]
<Ober>
irc is hard
mulk has joined #lisp
gxt has quit [Remote host closed the connection]
gxt has joined #lisp
<decent-username>
lel
Jeanne-Kamikaze has joined #lisp
<decent-username>
Ober: not when you use emacs
<decent-username>
:^D
<decent-username>
I tried figuring out weechat, but that was to leet for me.
<decent-username>
I'm not a real haxor.
hiroaki has quit [Ping timeout: 245 seconds]
nowhere_man has joined #lisp
fanta1 has quit [Quit: fanta1]
chip2n has joined #lisp
shifty has quit [Ping timeout: 240 seconds]
slyrus_ has joined #lisp
chip2n has left #lisp [#lisp]
chip2n has joined #lisp
hiroaki has joined #lisp
slyrus__ has joined #lisp
slyrus has quit [Ping timeout: 265 seconds]
slyrus_ has quit [Ping timeout: 240 seconds]
retropikzel has quit [Remote host closed the connection]
bendersteed has joined #lisp
spike_qi has joined #lisp
manualcrank has quit [Quit: WeeChat 1.9.1]
FreeBirdLjj has joined #lisp
monokrom has quit [Remote host closed the connection]
spike_qi has quit [Ping timeout: 268 seconds]
cosimone_ has joined #lisp
cosimone has quit [Ping timeout: 250 seconds]
nowhere_man has quit [Ping timeout: 264 seconds]
cods has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
cosimone_ has quit [Client Quit]
cosimone_ has joined #lisp
jcowan has joined #lisp
hiroaki has quit [Ping timeout: 268 seconds]
cosimone_ has quit [Client Quit]
<jcowan>
Is there a way to make class instances evaluable as opposed to applicable, so that when eval is handed one, it calls some code that gives the value of the instance?
nowhere_man has joined #lisp
cosimone has joined #lisp
<pfdietz>
That would violate the standard, jcowan.
<pfdietz>
A form that is neither a symbol nor a cons is defined to be a self-evaluating object. Evaluating such an object yields the same object as a result.
<pfdietz>
(quoting there)
<jcowan>
Ah. Bummer.
cosimone has joined #lisp
<pfdietz>
One must be careful putting such things into forms, since if they do not have load forms they can't go in binary files.
<beach>
selwyn: And I can totally see how drmeister made the choice to write a Common Lisp implementation that interoperates with C++ rather than taking on the task of rewriting all the libraries he needs for his molecule design.
McParen has left #lisp [#lisp]
cosimone has quit [Client Quit]
<pfdietz>
One should not, for example, put function objects into forms, but rather use (function <function-name>).
<pfdietz>
I consider this a defect of the language, and would like things like functions or environments to be able to be put in binary files.
<jcowan>
That requires reifying the lexical environment, which is very bad for performance.
<beach>
The defect is the existence of FASL files.
* beach
is half joking.
<beach>
jcowan: What does?
<jcowan>
Being able to output an arbitrary closure so that it can be applied at the other end, for some value of "end"
<beach>
Sometimes, one needs to put functions into forms, for example for computing a discriminating function out of effective methods.
<beach>
jcowan: I don't see that. The lexical environment is long gone by the time you have a closure.
<pfdietz>
The place this came up for me was in implementing mutation testing for Common Lisp. I want to be able to replace definitions of functions, even if they are in nontrivial lexical environments.
<pfdietz>
So I want to keep that lexical environment around in some form, so I can plug mutated versions of the function into it.
akoana has joined #lisp
<jcowan>
Wrapping your function definition in a hand-created let does the job, but you have to have the information necessary to create that let, hence reification
UrbanPoultry has joined #lisp
<beach>
pfdietz: That idea is kind of contrary to the one of "minimal compilation". You would need to mutate the source before it is minimally compiled.
<pfdietz>
I lean in this direction: require the ability to query the lexical environment, so one can, when compiling the original function, record the necessary information. Then, when the function is mutated, use that information to synthesize something that behaves like that environment.
UrbanPoultry has left #lisp ["Leaving"]
UrbanPoultry has joined #lisp
<beach>
pfdietz: Sounds like you want to use Trucler.
<pfdietz>
For example, if there is a (let ((x ...)) (defun foo ...)), when foo is compiled information would be stored that would let one access x. Accessor and settor thunks.
<beach>
Trucler is a library that supplies lexical environments in way defined by a complete protocol.
<pfdietz>
Well,I'm fine with doing it in a single lisp implementation (read: sbcl), but portability could be nice.
<beach>
As it turns out, heisig has written an SBCL implementation of the protocol, using SBCL native lexical environments.
<beach>
Trucler also has a "reference implementation" that I use for SICL.
vlatkoB has quit [Remote host closed the connection]
<beach>
Cleavir version 2 uses the Trucler protocol, but Cleavir clients can choose to use the reference implementation or an implementation-specific one.
UrbanPoultry has left #lisp ["Leaving"]
<beach>
But since SICL is a new implementation, it does not have any historical baggage when it comes to its lexical environments, so it may as well use the reference implementation.
<pfdietz>
jcowan: wrapping the function in a hand-created let will not do the job, since I want to be able to access the same lexical variables, which may be shared with other functions.
<jcowan>
Boxes and assignment conversion fix that problem, then all the let variables are immutable.
clothespin has joined #lisp
nika has quit []
Necktwi has quit [Quit: leaving]
gareppa has joined #lisp
Involuntary has joined #lisp
bendersteed has quit [Quit: bye]
Jeanne-Kamikaze has quit [Ping timeout: 268 seconds]
gareppa has quit [Quit: Leaving]
<jcowan>
Hmm, does any CL still implement *evalhook*? That would do the job, though at considerable expense.
<MichaelRaskin>
Well, one can just code-walk the corresponding top-level form, find the function definition and replace it
<jcowan>
No, I meant my original question about evaluable objects.
<jcowan>
s/objects/instances
cosimone has joined #lisp
<pfdietz>
CLISP has *evalhook*
<jcowan>
the hook function could identify an evaluable instance, call its evaluator, and return the result.
<pfdietz>
sbcl does not
<jcowan>
makes sense, it doesn't seem well-suited to a language whose eval compiles.
* jcowan
goes and looks at the ANSI issues
no_gravity has joined #lisp
<no_gravity>
Good Evening
<no_gravity>
Would you guys consider Bel a strongly typed language?
<Shinmera>
Ask ##lisp, this channel is about Common Lisp.
clothespin has quit [Ping timeout: 268 seconds]
makomo has joined #lisp
makomo has quit [Client Quit]
Fare has joined #lisp
<no_gravity>
Shinmera: Would you consider Common Lisp a strongly typed language?
EvW has joined #lisp
<Shinmera>
Yes.
<Shinmera>
I wouldn't just consider it one, it is one.
<no_gravity>
I don't know much about Lisp. But I was under the impression it can change its own behaviour.
<no_gravity>
So it could escape the straightjacket of types?
longshi has joined #lisp
<Shinmera>
I don't know what that means. In Common Lisp every value has a type. This type may only be known at runtime, so it is dynamically typed, but the type is nevertheless a strong one.
<no_gravity>
When you say "every value" - is that similar to "every varible" in other languages?
<Shinmera>
a variable holds a value.
<Shinmera>
this is the same in every language.
<no_gravity>
How would you wite this in CL? a=7
<pfdietz>
Common Lisp is strongly typed, just not (always) statically typed.
<pfdietz>
Assignment? (setq a 7)
<pfdietz>
More typically one binds variables, though.
<pfdietz>
(let ((a 7)) ...)
<no_gravity>
Ok, and how do you write this? a=7; echo a; a="hello"; echo a;
<pfdietz>
(setq a 7) (echo a) (setq a "hello") (echo a)
<aeth>
Idiomatically, we'd use two LETs and it would never rebind the old a. Literally, you can just use a setq or setf.
<pfdietz>
Assuming one had a function named echo
<no_gravity>
pfdietz: So you can assign a string to a variable that previously was a number?
<pfdietz>
Yes
<pfdietz>
Unless you've given that variable a type declaration, in which case that would be invalid (and a lisp like SBCL would check for it)
<Shinmera>
again, strong, dynamic types.
<aeth>
no_gravity: As long as there wasn't an attached type declaration to the binding, in which case it's implementation specific
<Shinmera>
please read up on what the terminology means.
<aeth>
Strong typing afaik means that it's not an autocoercive language like those that try to make sense of: 1 + "hello"
<no_gravity>
There are "attached types" in Common Lisp?
<pfdietz>
In practice, if you've done something stupidly wrong, like have a program where + is applied to a non-number, an implementation like sbcl will warn you when code would cause a runtime error due to type incompatibility.
<pfdietz>
Attached types? What are those?
<aeth>
Type tags, maybe?
<pfdietz>
All values in CL have a type.
<aeth>
Implementation detail, but probably tagged.
<pfdietz>
There is a function, type-of, that tells you the type of a value.
moldybits has quit [Quit: WeeChat 2.4]
<pfdietz>
Getting this to work efficiently is interesting.
<no_gravity>
pfdietz: Why do you use the term "values" instead of "variables"?
<pfdietz>
Because values have types, not variables, in Common Lisp.
<Shinmera>
I assume he means non-null types and other static reasoning you can do about code if you have static typing and non-null types
<Shinmera>
no_gravity: Do you have any intention of learning Common Lisp, or are you just trying to use us to not have to read up on basic programming language terminology?
<pfdietz>
(type-of '(a . b)) ==> CONS in SBCL, for example.
cosimone has quit [Quit: Quit.]
<no_gravity>
Shinmera: I would say neither.
<Shinmera>
I won't invest any more time in replies, then.
ralt has joined #lisp
<pfdietz>
no_gravity: absent declarations, a variable in CL can hold a value of any type.
<pfdietz>
Also, types are richer than in many statically typed languages. For example, the type T holds all values.
<no_gravity>
pfdietz: Interesting. How do you define a function in lisp? Say this one: function f($name) { echo "Hello $name" }
<pfdietz>
(defun f (name) (format t "Hello ~a~%" name))
<pfdietz>
So, (f "foo") would print
<pfdietz>
Hello foo
<pfdietz>
And (foo 1) would print
<pfdietz>
Hello 1
<no_gravity>
pfdietz: So you can pass any type of value to f?
<no_gravity>
I would call that a loosely typed language.
<pfdietz>
The parameter name could be any printable value.
<pfdietz>
It's dynamically typed. Type errors are caught, but at run time, not compile time.
<pfdietz>
Contrast this to a language where type errors cause crashes.
moldybits has joined #lisp
<pfdietz>
(some type errors are caught at compile time, in practice, since the compiler typically does some type propagation then and can detect many problems)
<no_gravity>
Ah yes, dynamically typed.
duuqnd has quit []
cosimone has joined #lisp
<jcowan>
it's obvious that (+ 1 "foo") is ill-typed, so the compiler can transform it into code that raises an exception
Involuntary has quit [Quit: Leaving]
Jeanne-Kamikaze has joined #lisp
<jcowan>
in Scheme a compiler can reject the whole program outright.
cosimone has quit [Read error: Connection reset by peer]
cosimone has joined #lisp
shka_ has quit [Ping timeout: 268 seconds]
prite has quit [Ping timeout: 240 seconds]
salinasc has quit [Ping timeout: 265 seconds]
clothespin has joined #lisp
karlosz has quit [Quit: karlosz]
no_gravity has left #lisp [#lisp]
Fare has quit [Ping timeout: 264 seconds]
Arcaelyx has joined #lisp
shka_ has joined #lisp
vaporatorius has quit [Ping timeout: 268 seconds]
gravicappa has quit [Ping timeout: 240 seconds]
manualcrank has joined #lisp
FreeBirdLjj has joined #lisp
cosimone has quit [Read error: Connection reset by peer]
cosimone_ has joined #lisp
cosimone_ is now known as cosimone
FreeBirdLjj has quit [Ping timeout: 240 seconds]
nullman has quit [Ping timeout: 264 seconds]
Fare has joined #lisp
lxbarbosa has quit [Remote host closed the connection]
nullman has joined #lisp
gareppa has joined #lisp
clothespin has quit [Ping timeout: 268 seconds]
jasom has joined #lisp
ggole has quit [Quit: Leaving]
Fare has quit [Read error: Connection reset by peer]
flak has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
cosimone has quit [Quit: Quit.]
gareppa has quit [Read error: Connection timed out]
cosimone has joined #lisp
gareppa has joined #lisp
cosimone has quit [Client Quit]
Fare has joined #lisp
space_otter has joined #lisp
aindilis has quit [Ping timeout: 240 seconds]
decent-username has quit [Ping timeout: 246 seconds]
longshi has quit [Ping timeout: 252 seconds]
Fare has quit [Read error: Connection reset by peer]
gareppa has quit [Quit: Leaving]
jfb4` has joined #lisp
jfb4 has quit [Ping timeout: 265 seconds]
aindilis has joined #lisp
enrio has joined #lisp
Fare has joined #lisp
wooden has quit [Read error: Connection reset by peer]
random-nick has quit [Ping timeout: 268 seconds]
Fare has quit [Read error: Connection reset by peer]
sauvin has quit [Ping timeout: 240 seconds]
raghavgururajan has joined #lisp
davisr has joined #lisp
ltriant has joined #lisp
Fare has joined #lisp
salinasc has joined #lisp
igemnace has quit [Quit: WeeChat 2.6]
shka_ has quit [Ping timeout: 240 seconds]
Fare has quit [Read error: Connection reset by peer]
sauvin has joined #lisp
longshi has joined #lisp
torbo has joined #lisp
quazimodo has joined #lisp
bjorkintosh has quit [Quit: Leaving]
nowhere_man has joined #lisp
varjag has quit [Ping timeout: 240 seconds]
Jeanne-Kamikaze has quit [Quit: Leaving]
vms14 has joined #lisp
<vms14>
(format t "~a ~{ ~a ~} ~:*~a" 1 '(2 3 4))
<vms14>
how I return to the 1?
enrio has quit [Quit: Leaving]
<vms14>
oh lol
<vms14>
just adding another ~:*
ralt has quit [Quit: Connection closed for inactivity]
<vms14>
could I do another loop with ~:* taking the list again?
<fiddlerwoaroof>
Format directives take numeric arguments
<fiddlerwoaroof>
I forget the order :), but it's something like ~:2*
<fiddlerwoaroof>
I wonder if beach's sicl could be used for sandboxed lisp execution in minion
gdsg has quit [Remote host closed the connection]
<fiddlerwoaroof>
it'd be cool to be able to ask minion to evaluate a form and print the result
<vms14>
I'd be cooler to be able to invite minion to your own channel
<fiddlerwoaroof>
You can always run it yourself :)
<vms14>
nah
<vms14>
I just wanted the "memo" feature
<aeth>
vms14: Imo, using format for everything, while possible (at least once you mix in "~/package::foo/"), is probably not the best thing as far as readability goes. It's like regexp for everything.
<aeth>
vms14: Well, at least one format call. Even just breaking things up to 5 or so formats with things like loop mixed in can help with readability
<vms14>
I have to learn how to make functions for format
<vms14>
I have to learn a lot xD
longshi has quit [Ping timeout: 276 seconds]
<aeth>
It works as expected, it's just that you need to always include the package prefix (or else it assumes cl-user, which is weird) and this means you can't use / in package names (which is increasingly common)
<vms14>
format function calls seem to be very good for analize/extract data before printing
<vms14>
I want to learn also the reader macros
<vms14>
they let you change the syntax completely
<fiddlerwoaroof>
First you learn to write reader macros and then you learn not to write reader macros :)
<vms14>
and you can maintain several readtables so you could have different syntax blocks
<aeth>
In practice, unless you actually want it configurable with : and @ you basically just do this: (defun foo (stream argument &rest rest) (declare (ignore rest)) ...)
<vms14>
fiddlerwoaroof: why not?
<fiddlerwoaroof>
most reader macros end up breaking paredit and other editor features
<vms14>
what makes them break?
<fiddlerwoaroof>
And, as a rule, normal macros "feel" better
<vms14>
a specific syntax I suppose
<aeth>
vms14: I mean, I think we've all been there before with some features of some programming languages, where we learn it, push it to its limits, and then realize that we can't read it the next day, and eventually decide moderation is best, like all things.
<aeth>
vms14: I just suspect you'll get there with FORMAT eventually
<aeth>
At least to me, it's a lot plainer to use multiple write-foo/prinfoo/format instead of trying to fit everything in one format
<fiddlerwoaroof>
So, the more you change the syntax with reader macros, the worse your editing experience gets
<vms14>
aeth: yes, I should do that too
<aeth>
fiddlerwoaroof: Unless you also configure that!
bjorkintosh has joined #lisp
<aeth>
vms14: because it's a stream (with a few extras for FORMAT that might not apply to the rest), you can basically mix and match except for (format nil ...) where you're generating a string with the return value (but even there you could concatenate)
<fiddlerwoaroof>
There are some exceptions, like my objc-lisp ffi
<vms14>
is you can use format inside format functions
<fiddlerwoaroof>
I find these square-brace macros make the ffi part a lot nicer-looking (because it papers over a lot of the ffi noise)
<aeth>
vms14: Personally, even if I'm 100% using FORMAT, I would keep it to one line, even though one super format string can technically do more, except perhaps for a fairly trivial ~{ ~} usage (but even that I'd mostly use to e.g. turn '(1 2 3) into "1, 2, 3" instead of doing that for lines)
<aeth>
And sometimes one line is too much
<vms14>
I'd be happier with M expressions than with S expressions just because {} or [] is faster than write ()
<vms14>
type*
<aeth>
you can change your keyboard layout
<vms14>
or make a reader macro
<fiddlerwoaroof>
I use the OS to bind left and right shift to open and close parens
<fiddlerwoaroof>
It's amazing, once you get used to it
<vms14>
fiddlerwoaroof: lol
<fiddlerwoaroof>
It's a really cool idea: when you press shift by itself, it enters a paren, when you push it with another key it inserts a capital