freenode/lisp - IRC Chatlog
Search
14:05:04
_death
since a long time ago, I've been wary of technologies with "x" or "j" in their name.. in recent years "smart" also proved a good needle
17:08:02
rpg
Here is a deeply random question: does anyone know if CLIM/SLIME style presentations exist for other programming languages/programming language modes? I have to do a bunch of python these days and I miss the SLIME inspector *really* badly.
17:10:27
rpg
verisimilitude: hm... probably just as easy to try to smash SLIME onto python directly as to use forth as a conceptual bridge...
17:11:23
verisimilitude
I thought you were simply asking about languages with similar facilities, not a language to bridge with.
17:11:28
rpg
verisimilitude: Yes, what I would like to do is have a python mode that, like SLIME, has mouse-able data structures.
17:12:50
verisimilitude
I'm familiar with the name iPython to refer to some fancy Python environment; have you tried that?
17:13:04
verisimilitude
Also, there's a Python implementation in Common Lisp, so you could simply use that.
17:14:03
rpg
verisimilitude: I'm using python (like many people) because I need access to numpy, pandas, and some machine learning libraries; I'm not sure that would be possible in a CL port of python.
17:15:04
verisimilitude
It's amusing to me how people write in Python, but not for Python itself, as Python is a poor language.
17:15:40
rpg
verisimilitude: I think Python is underrated; they have gone out of their way to pull a lot of the nice features of Lisp, CLOS, etc.
17:16:04
verisimilitude
The creator has gone out of his way to gimp many features as well, lambdas, TCO, etc.
17:16:08
rpg
I still miss "homoiconicity", and things like CHANGE-CLASS for a long-lived environment.
17:17:06
rpg
verisimilitude: Ah! I came up with only Total Cost of Ownership, which isn't quite right!
17:17:41
verisimilitude
Python instead has a default stack limit of 1,000 and doesn't perform TCO purely because Guido doesn't care for it.
17:18:31
rpg
verisimilitude: One thing I am appreciating is optional type checking (mypy, pyre), which I really wish I had in CL.
17:20:41
rpg
dlowe: I like the checking that SBCL does, but I confess to a long term lack of understanding and queasiness about SBCL's use of CL type declarations for checking instead of (in addition to) optimization
17:22:12
rpg
I have an old copy of Drew McDermott's Nisp lying around, which does type checking, but it's written in such an idiosyncratic style that I've never managed to successfully comprehend it.
17:52:26
sukaeto
IIRC, if you put type declarations in your code, SBCL tells you when you make a type error
17:55:30
sukaeto
minion: memo to rpg: you could try out elpy. I've used it a bit with iPython in inferior Python mode. It's not as nice as SLIME, and I eventually stopped using it, but it might give you what you want.
18:02:14
anamorphic
Hi, I have some foreign code that deals with a pointer to two kinds of things: FOO and BAR, but in my CFFI code, I'd like to prevent a FOO pointer being passed to a function where BAR pointer is expected, so I came up with this scheme: https://pastebin.com/YU7fx2XK but it feels like I'm probably re-implementing something. Is there a better way to go?
18:57:04
phoe
anamorphic: I don't think so. CFFI pointers are not typed, so having a simple structure wrapper around them is the way to actually keep them typed in the Lisp world.
19:13:22
Bike
cffi does maintain types for pointers, it just ignores them, right? would it be difficult/possible/a good idea to have it type check those?
19:15:37
|3b|
at least on sbcl it just returns an (untyped) sbcl pointer value, with no extra cffi type info as far as i know
19:24:39
phoe
I mean, the returned pointers are not typed in any way and a pointer returned from a function that is supposed to return an int pointer can be dereferenced as a float pointer later on and no type errors will happen.
19:25:10
phoe
I suppose it could, sure - it won't be backwards compatible, obviously, but the type information could be stored somewhere and then checked.
19:25:43
LiamH
I think the reason for the pointer types is for conversion on dereferencing, especially for structs.
19:28:39
phoe
LiamH: you can't dereference a pointer in CFFI without providing the type that you want to dereference as.
19:41:10
sjl_
> Pointers do not carry around type information. Instead, type information is supplied when pointers are dereferenced.
19:41:12
sjl_
> A type safe pointer interface can be developed on top of an untyped one. It is difficult to do the opposite.
19:46:34
LiamH
cffi-libffi, which allows for struct by value call/return, required the type of the struct be specified in order to do the conversion. As a convenience, the ability to specify the type of pointer was added to facilitate similar conversion for call-by-reference, though I don't think that is implemented.
20:07:30
phoe
karlosz: get yourself a fresh int pointer, write a uint32 to it, read a sint32 from it