freenode/#lisp - IRC Chatlog
Search
4:42:40
LdBeth
Otherwise you have to start from applicative Lisp, which has significantly less features
4:43:14
aeth
LdBeth: You can extend Common Lisp more easily than Scheme because you can do it mostly in Common Lisp
4:45:32
aeth
Anything's possible, but if your Scheme is 90% C that means (probably) writing most of your new features in C.
4:52:04
aeth
LdBeth: Yes, but it wouldn't be a new implementation. Adding a good static type system to SBCL would be no more involved than adding threads or unicode. (The other implementations might be trickier. SBCL already is half of the way to being a statically typed lisp.)
4:54:18
jackdaniel
aeth: that's some weird and inaccuarate claim for a language which is specified to be dynamically typed ;/
4:55:27
jackdaniel
I'm afraid you mix terms. Gradual typing allows you to have some variables typed, static typing is when all types are known at the compilation time
4:56:46
jackdaniel
no, terms in this case are not a matter of opinion, please do not use them inproperly because it only increases the confusion
4:58:30
jackdaniel
(regarding SBCL having a support for gradual typing – I have no information on that topic)
5:01:44
aeth
interestingly, Wikipedia calls it "soft typing", not "gradual typing". https://en.wikipedia.org/wiki/Type_system#Combining_static_and_dynamic_type_checking
5:05:18
aeth
jackdaniel: As to how it does gradual typing: Most of SBCL's static type checking is done within one file (or within one with-compilation-unit). It also has sb-ext:*derive-function-types* which defaults to NIL that assumes function types never change (which is NIL because it's non-standard behavior).
5:06:55
aeth
It's afaik based on the function metadata, so if it knows at compile time that the x in (sin x) isn't a number it can complain (since functions in the CL package can't be redefined, it always behaves like this for functions in the CL package). e.g. (defun foo () (let ((x "foo")) (sin x)))
5:08:41
jackdaniel
I would be inclined to believe, that this one is a matter of type inference which is perfectly fine within dynamic typing paradigm. I need to go now though
5:11:25
aeth
You can DECLAIM FTYPE for the function or DECLARE TYPE for individual input variables to the function and it will use those in the same system. e.g. (with-compilation-unit () (defun foo (x) (declare (integer x)) (sin x)) (defun bar () (foo 42f0)))
5:12:38
aeth
Imo when it infers the ftype, it's type inference, when it respects the type declaration it's static type checking. (foo 42f0) will work perfectly fine in CLISP and will probably be caught only at runtime in many implementations that do something with type declarations.
5:15:12
aeth
You could also have it catch something like (in case 42f0 is too type inferency): (with-compilation-unit () (defun foo (x) (declare (integer x)) (sin x)) (defun bar (x) (declare (single-float x)) (foo x)))
5:21:21
LdBeth
aeth: Although I agree there will be no necessity distinguish static or dynamic types in foreseen future, and I think I know what you mean, that is not the thing I expected to be well integrated with CL. For example, how will the method dispatch work in such a type system?
5:21:37
aeth
What's missing is (1) a way to store non-T (just structs and specialized-arrays and declared/declaimed variables afaik) and (2) a way for you (not the compiler) to do something meaningful with ftypes.
5:22:15
aeth
LdBeth: There's always https://github.com/markcox80/specialization-store/ but not everything is exposed to it by the implementations (and what is varies).
5:24:13
aeth
(oh, I forgot that you can declare conses, I think the way it's done requires walking through the list to verify each time? Instead of just having a foo-list that you can just check the first element since its cdr must be foo-cons or nil)
5:26:15
aeth
LdBeth: Anyway, I personally think you could (for the most part) add the useful stuff from modern static type systems to an existing Lisp (which would make the result gradually typed! I'll concede that!) and have it just work alongside what's already there, just like they added the useful stuff from modern OOP to existing Lisps in its own, Lispy way.
5:30:08
astronavt
i just like types because, as a programmer, it means i need to keep less in my brain at once
5:30:42
LdBeth
Blah, I don’t think there’s any wrong using a existed implementation, but I discourage to actually do it without some common agreements on how would the type system work
5:33:24
fiddlerwoaroof
But, the "types as macros" paper focuses on a DSL for describing the type systems of DSLs while Hackett is trying to be a Ha(skell) built on top of (Ra)cket[t]t
5:33:24
aeth
LdBeth: I disagree what you say about gradual typing being useless, btw. Everything has a static type, it's just usually T. You could still do useful things as long as the part of a program that heavily uses types don't have to break out of it. Right now, you would because you basically can, with few exceptions, only store T. Put an integer in a hash table and then take it out in that same function and SBCL will forget it's an integer iirc.
5:35:03
fiddlerwoaroof
Hackett is interesting because the types are about more than correctness, because it has bidirectional type inference, the types can be used to pick which implementation of your functions to use and are not limited to just checking correctness.
5:35:32
LdBeth
If everything is T, having gradually type doesn’t make a difference on optimization or safety
5:36:07
aeth
LdBeth: As it is right now, SBCL can infer or use the declarations for a lot of things, especially numbers and arrays.
5:36:51
fiddlerwoaroof
i.e. in most type systems, if you erase the types, the program still makes sense. With a haskell-style type system, the types can be used as a kind of "global" macro
5:37:17
aeth
It would be a very unlispy thing to *force* people into declaring types, though, even if you *could* make a program that was 100% known-at-compile-time types (which you can't really do right now except for numeric code)
5:37:33
aeth
Lisp is about giving you everything and then if you want to have a certain style you discipline yourself into using that style.
5:38:03
aeth
Forcing people into static type declarations for static type checking would be very unlispy, but optionally permitting everything to have known-at-compile-time types isn't unlispy.
5:39:40
astronavt
in some cases you can make the program run faster by declaring types, which helps the JIT compiler optimize
5:40:11
aeth
LdBeth: SBCL is basically there right now with inference except (1) the main boundary is the function, (2) the even larger boundary is the file or the compilation-unit, and (3) you'll usually lose type information once you store things into a data structure.
5:40:30
astronavt
yeah im not saying Julia did it first. just that its a high quality modern example of it working very well in practice
5:40:45
aeth
And types for performance are basically only really necessary when there are generic things like + (works on any number) or map (works on any sequence)
5:41:23
fiddlerwoaroof
LdBeth: I believe type inference (at least Hindley-Milner type influence) was invented by the people that made ML
5:41:25
aeth
Otherwise e.g. even though it's T when you call CAR on foo, it's going to be a LIST-or-ERROR so the compiler can still make some assumptions
5:42:17
astronavt
i imagine you could abuse it pretty badly though, relying on IDE to tell you what's happening
5:42:23
fiddlerwoaroof
Yeah, wiki claims that ML was first: https://en.wikipedia.org/wiki/Hindley–Milner_type_system#History_of_type_inference
5:43:01
LdBeth
a first class type system, where types can be calculated and compose without a special concept of run time and compile time
5:45:09
jackdaniel
LdBeth: that makes no sense. what you call "analysis of program" I call a phase of compilation (just like when macros are expanded)
5:46:12
aeth
macros are in their own phase because they get you 95% of what you want with the alternative (what are they called? fexprs or something?) but with a ton more performance
5:47:13
LdBeth
jackdaniel: Lisp probably lacks fancy industrial level features like formal verification, which is where a sophisticated type system will contribute
5:47:25
aeth
(Well, potentially performant. The Common Lisp police aren't going to arrest you for making a slow Common Lisp interpreter.)
5:48:09
aeth
LdBeth: Imo, you can't get perfect verification with Common Lisp because too much of its behavior relies on global *foo*s.
5:51:08
fiddlerwoaroof
LdBeth: one of the major formal verification systems uses a subset of common lisp
5:52:12
aeth
LdBeth: I guess you could watch the globals to see if anything set them if you don't want to just subset CL.
5:52:51
fiddlerwoaroof
Yeah, it's total (i.e. every function must produce a value in a finite amount of time) so you don't have to deal with the halting problem
5:54:38
fiddlerwoaroof
Yeah, I've been putting off the Mojave upgrade until I'm confident that people have worked out the issues
5:55:59
LdBeth
the latest development snapshot compiles, but sometimes quit under high memory pressure.
6:17:58
phoe
https://cdn.discordapp.com/attachments/297478350145060875/505263455415304213/tcle-alexandria.pdf
10:12:29
devon
no-defun-allowed: Never heard of ql:register-local-projects - until today, everything in the local-projects directory simply worked.
10:21:44
devon
ql:quickload can't find a system listed by (ql:list-local-systems) so not really fixed.
10:25:58
jackdaniel
I'm not sure who is at fault, but CCL or ASDF doesn't behave well with symlinks to directories when it comes to looking for a system
10:27:00
jackdaniel
from workarounds which may work (in case of local projects) it is to call register-local-projects *from* sbcl and then launch ccl
11:50:30
shka_
heisig: is there a video of you with this presentation? https://www.european-lisp-symposium.org/static/2018/heisig.pdf
11:51:47
heisig
shka_: In theory, yes. But as far as I know the ELS recordings have not been uploaded (yet?).
11:53:51
beach
shka_: I suggest you organize ELS and see what it's like. Then people can say that your organization sucks.
11:55:08
shka_
i don't know if organization of event was good or bad, i know that videos are not available yet
11:57:05
shka_
this probabbly says more about unsufficient manpower behind editing of those videos more then anything else
14:21:22
knobo
Is it possible to find out what state the compiler is in when my load fails? (:compile-toplevel or :load-toplevel etc)
14:23:23
Bike
the backtrace should make it fairly obvious if it's in the middle of the compiler. you can also look whether fasl files have been produced.
14:25:57
knobo
if i do (defvar *web* (make-instance '<web>)) it works, but if I import *web* from another package, and then do (setf *web* (make-instance '<web>)) it fails.
14:28:21
knobo
Bike: the make-instance hash a initialize-instance method that is not called before it's too late.
14:29:27
knobo
Bike: so later in the code I get There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION (COMMON-LISP:SETF NINGLE.APP:ROUTE) (1)> when called with arguments .....
16:06:54
Bike
i think i'm thinking of "Clef Design: Thoughts on the Formalization of Program Construction", but i guess it's not online
16:09:51
warweasle
I was thinking of using something like this as remote "datablocks" which would make a great base for a multi-user editor.
16:23:00
scymtym
pfdietz: interesting. maybe talk to eschulte (the author of the above). see https://github.com/robert-strandh/Eclector/issues/28 for a bit of context
16:25:13
scymtym
oh, i didn't read your message that way :) i read it in the independent-invention sense