freenode/#lisp - IRC Chatlog
Search
12:28:18
no-defun-allowed
You are allowed to download it, maybe you aren't allowed to redistribute it unless some specific rules are met, it's probably not compatible with the other licenses of Portacle components, but IANAL and neither is anyone working on Portacle.
13:35:25
eigenhombre
Morning again. Did some more research on my CFFI / SBCL / problem yesterday following up on your suggestions and captured my findings here: https://stackoverflow.com/questions/57906498/installing-sbcl-ffi-packages-on-mac-via-quicklisp . Any hints on SO or here would be greatly appreciated!
15:51:04
thijso
I've been fixing a number of c-inline stuff in ECL and usocket these past couple of days.
15:52:20
thijso
However, I now seem to have a state where I can actually use one of the logging packages I tried earlier. log4cl and verbose both ended up having the same issue, but now that I've gotten my patches merged I can try using one of them again. (<- Shinmera )
15:53:49
thijso
pjb: well, I'm "forced" to do that, otherwise what I'm actually working on wouldn't work (or get nice UNKNOWN_ERROR's sprinkled everywhere...)
15:55:05
thijso
asdf_asdf_asdf: what do you mean? I've found the (or, at least some) issues and fixed them. Now I can go back to what I was originally working on
15:56:25
thijso
I'm actually a little shocked at how unfinished a lot of stuff seems in relation to ECL. In ECL code itself, but also supporting code in for example usocket and bordeaux-threads
15:57:02
thijso
asdf_asdf_asdf: problem already solved. This, for example: https://github.com/usocket/usocket/pull/55
15:58:21
asdf_asdf_asdf
Someone know which instruction in aliens instructions is void* and null from C?
16:00:06
thijso
Comments like ";; really big FIXME: This whole copy-buffer thing is broken." in SBCL sockets.lisp also doesn't really inspire a lot of nice fuzzy feelings...
16:01:16
Shinmera
thijso: I think in ECL's case it's because it didn't recieve a lot of love until jackdaniel picked up as maintainer.
16:02:48
thijso
Yeah, not complaining. It's just that I usually work in SBCL and haven't had the experience of these kinds of issues before. However, I'm stuck with ECL for now. Unless anyone knows of other ways to build android apps in Common Lips (that don't cost money).
16:03:10
thijso
But, on the other hand, seeing that comment in the SBCL source code... maybe I've just been lucky ;)
16:05:29
pjb
thijso: ecl is basically a one-man operation. The miracle, is that there has been one man for so long to make releases so far…
17:55:09
jackdaniel
pjb: that might have been true for some time, but right now we have two regular maintainers and a steady stream of 3rd party contributions
18:59:38
aeth
whartung: I think the main difference is that CL's type system is typical in that deftype is just a renaming, but afaik in Ada if you ask for a Foo you must get a Foo even if it's just defined as a range 10 .. 20 or a mod 24 (both of which CL has an equivalent for). That even wouldn't really work in CL. How would you make 13 be specifically of type foo in CL? Doesn't really work well without full static typing.
19:03:11
aeth
One thing I see here in Wikipedia (and I think I've mentioned this here once before!) is that there's pretty much a CL equivalent for every example here except the second subtype. You can represent weekdays as '(member :monday :tuesday :wednesday :thursday :friday :saturday :sunday) but you can't then do (range :monday :friday) as working-days. https://en.wikipedia.org/wiki/Ada_(programming_language)#Data_types
19:03:28
aeth
member types are, afaik, unordered, although the implementation will probably test them in the order you defined them.
19:04:43
aeth
There also isn't a defsubtype, just a deftype. I guess the difference is that a defsubtype would have to determine that your definition is a subtype of a provided type in addition to defining the type. This could get complicated (or impossible?) if you provide arguments to the deftype or hypothetical defsubtype
19:05:29
aeth
whartung: And those are all of the differences I can get from public information on Ada without knowing Ada. There are probably more.
19:06:34
sjl_
Bike: can you rely on (check-type foo '(and t1 t2)) to check that foo is of type t1 before t2?
19:06:50
sjl_
> For example, the type specifier (and integer (satisfies evenp)) denotes the set of all even integers.
19:08:49
sjl_
I suppose. Seems odd that they would choose an example that would be broken if used with typep or check-type...
19:08:56
pjb
Bike: it is not structural: (deftype p1 x y) (deftype p2 x y) (p2-x (make-p1 :x 1 :y 2)) is not conforming!
19:11:09
Bike
well what i mean is that the deftype mechanism doesn't add any type names that affect resolution of type system questions. it is true you can name different struct types
19:13:45
pjb
Lisp is a generic programming language. Meaning that most code you write is just not typed, it's "template code" or "generic code". It can transport data of any type. It's usually left to the client code to determine what gets in, and what it gets out.
19:14:17
pjb
Take for example sort. sort can work on sequences of anything, you just give it a lessp function.
19:16:01
pjb
On of the tests to know if a person will be able to become a programmer, is to check if that person is able to reason with boxes, abstracting the contents. Trying th re-introduce restrictions on boxes such as boxes that can hold only numbers or only shoes doesn't help!
19:17:01
pjb
Of course, typing gives a lot of work to searchers and PhD students. It gives a lot of diplomas and university budgets…
19:20:12
sukaeto
as others have mentioned, you can have e.g. distinct range types which are incompatible with one another
19:25:59
sukaeto
in Ada, defining types is a large part of programming. The type system in Ada can help you make sure you're not making semantic errors (for a simple e.g. trying to multiply a speed and a distance when you meant to multiply a speed and a time)
19:27:18
sukaeto
it's a lot different from Lisp, where you (at least if you're me :-) ) just kind of grow code organically at the REPL
19:34:47
aeth
sukaeto: I was saying what I said under the assumption that it would apply even if you (with ordinary semantics) DECLAREd every variable in your functions/bindings, Ada-style, and even used an Ada-syntax reader macro, what would differ.
19:35:14
aeth
Of course, with that many macros, you could probably cons up additional type-tracking data structures to match Ada more precisely...
19:36:32
aeth
sukaeto: as for your specific problem (speed vs. distance), I wouldn't be surprised if Ada (or an extended Ada) had units in its type system
19:47:40
sukaeto
aeth: it doesn't provide them in the standard library, but they're easy enough to declare on your own
19:48:09
sukaeto
and I think GNAT (which is pretty much defacto Ada) provides a library that will generate the matrix for you
19:49:11
sukaeto
and yeah, of course you *could* implement such rich type level programming in Lisp. I mean, look at what the Qi/Shen team has done!
20:01:07
aeth
sukaeto: Defining types is almost always a large part of programming, though, and it just differs based on the language. e.g. usually that means defining classes.
20:02:49
aeth
I guess the main exception would be ultra-dynamic languages like Lua maybe? Just a bunch of tables there.
20:05:30
sukaeto
it's kind of hard to explain (well, without writing an entire essay on the topic). In Ada, pretty much everything is about types and the relationships between them.
20:06:00
whartung
yea, there’s just been more “Ada” traffic (seemingly) recently, and (mostly) focused on its type system. And while typing is idiomatically optional in CL, it seems that the CL type system is quite rich. Whether it’s rich enough, or enforced well enough, to opt as a stand in for Ada (if all you were interested in was a typed language, vs some other issue), that I don’t know. Unlikely, but was just curious by how much
20:06:59
whartung
and ceratinly not in every case, but whether there may be examples where the CL type system is “good enough” for someone who might else look at Ada
20:07:12
sukaeto
I think it's fair to say "you can do things in Ada out of the box with its type system that would require you to write a lot of macro code to achieve in Lisp"
20:08:06
aeth
whartung: Two problems. (1) You only get that richness if you use DECLARE, but DECLARE has undefined semantics (usually just means that it's ignored in some implementations, like CLISP) and the only implementation that normally handles it properly in almost all cases (SBCL) also does the worst (for reliability) semantics when at the (safety 0) optimization level, i.e. it assumes the type, like C.
20:08:21
aeth
DECLARE is fine, although you might want a macro for less-awkward syntax. I've written a lot of code both ways, thoguh.
20:08:25
whartung
but the key question is whether, even with enough macro code, was CL capable at all. How much of an overlap is there. The point about subtypes is important, i think, and structurally similarity — that may be a deal breaker
20:09:03
sukaeto
well, it's clearly capable. One could make the argument that Shen's type system is even more powerful than Ada's
20:09:28
sukaeto
while Shen is it's own thing now, it started out as just a bunch of Common Lisp macros, if I understand it correctly
20:09:50
aeth
whartung: The other problem (2) CL usually compiles file-by-file and leaves (almost, structs are undefined here) everything up for redefinition so unless you violate the standard with something like sb-ext:*derive-function-types* you won't get the full benefit of static typing outside of a single file and the CL package built-ins (and even in SBCL, you don't get quite the full benefit in a file because the style is so uncommon)
20:10:59
sukaeto
in any event, in Ada the type system's real value is in how the programmer an leverage it to get "provably correct" code
20:11:11
aeth
whartung: And relating problem #2 to problem #1, SBCL only does its static type checking when safety > 0 so you are actually less safe than in C/C++ where you'll at least get static safety without runtime safety! With SBCL you have both or neither, not C-level safety.
20:11:22
pjb
DECLARE is the user (programmer) giving hints to the compiler. It is by definition a bad thing.
20:11:33
sukaeto
(scare quotes because of course you don't get provably correct in general. But you can get some strong guarantees over some facets of the code.)
20:12:03
sukaeto
the extra efficiency the compiler can squeeze out given the extra information the types encode is just a bonus
20:12:08
aeth
whartung: Additionally, the ftype of a function that you get with DECLARE/DECLAIM-heavy code isn't exposed like the type information is. It's just for the compiler afaik.
20:13:04
pjb
The use of type in statically typed programming languages is to restrict the data flow. In dynamically typed programming language, the data flow is not restricted, we just check the type of the operands when needed. If you need to restrict the data flow, perhaps you should do so more explicitely than by just decclaring types. You should just write down the data flow, so to ensure that data that enters it doesn't leave it and no
20:13:25
aeth
pjb: You are incredibly, absolutely wrong as far as types go. There is a major difference between DECLARE and CHECK-TYPE where supported, and SBCL will take a CHECK-TYPE to mean that the variable before that point is of type T, since anything can be provided, and you can at runtime turn that into the item of the correct type during the CHECK-TYPE process.
20:13:42
pjb
Also, when you describe such data flow, you won't filter just by types, but you can and should filter more. For example, on units, or on the provenance of the data!
20:14:14
pjb
For example, there should be no reason to use a password from something else than physical user input.
20:14:43
pjb
That is, you need to tag the data by more than types, anything, and to filter on those tags.
20:16:10
aeth
sukaeto: Afaik, pjb is against gradual typing, so while CL implementations are able to support it, pjb argues against this.
20:16:22
sukaeto
if you're looking at a system like Java or C and you think that what they offer is all there is to type systems, then I can understand how you'd get that impression
20:17:00
pjb
I don't mind the compiler doing its job and signaling type inconsistencies early. But I don't want to have write anything about it.
20:17:56
sukaeto
given that I don't really think about types much beyond "this thing should be a number" or "this method specializes over these classes", I could probably agree with you there :-)
20:17:56
pjb
Checking them, most of the time. The programmer will too often be too specific in his type specifications.
20:19:12
whartung
I honestly use types in two places: one, when reading code just so I know what I’m looking at ,and 2, when refactoring to have the compiler let me know when I break things.
20:19:53
aeth
Ime, it really depends on what you do. For functions used by macros, types are incredibly useless. You want to basically be able to handle anything that is thrown at you in a given variable. If you're working with numbers, arrays of numbers, structs of arrays of numbers, etc., you absolutely wind up writing the 100th defun-with-more-convenient-type-declarations macro at some point.
20:20:40
aeth
(By incredibly useless in macros, I mean type declarations or even check-types. What you'd probably do at most is a typecase)
20:21:08
sukaeto
I can hot patch my running system in Lisp. I can just call anything that's been loaded at the REPL. When I hit bugs in development, the debugger just pops up and I get an interactive stack trace. Same with the profiler, it's just right there. I don't have to run the code with special flags to get it to dump some file that then has to be interpreted by another tool to give me output with the stuff I care
20:22:31
TMA
thinking about types helps me even in CL; but to be frank those are not the CL-types, these are more domain specific. (length-in-meters instead of number, sequence-of-issue-ids instead of list or list-of-integers)
20:24:14
pjb
But when you write your code, you should distinguish parts that are very sepcific to meters and issue-ids, and the rest of the algorithms that work on reals or list of integers (note, numbers are not lengths! Only real are lengths! you got your typing wrong (this is why you should let the compiler do it!)).
20:24:27
aeth
sukaeto: Ironically, C++, which everyone loves to hate, is probably one of the best of those rigid (more than just merely "static" imo) languages as far as runtime debugging goes. I mean, yes, you do get a vommit of error messages where only the first one is relevant if it's at compile, but if you want to look at something semi-interactively, you can just define << for it and print it.
20:24:36
pjb
What I'm saying is that 90% of your code will be generic code dealing with lists of whatever or lists of integers, or reals.
20:24:36
aeth
Assuming, of course, that you can recompile it fast enough to make it almost interactive!
20:26:48
aeth
pjb: If your "reals" are best modeled by floats, suddenly you probably are thinking about types and declarations, at least a bit. And if you're just handling text, you can probably just work with streams and not really worry about types that much because FORMAT is usually smart enough with ~A
20:28:08
TMA
sukaeto: as does haskell. haskellers are proud in that they manage to squeeze a lot into the type system
20:29:02
aeth
The reason I'm using CL instead of a more ideologically pure language is precisely because CL the language is less ideological than e.g. pjb is. If your code is almost all generic, good. It works. If your code isn't and it's almost all single-float/double-float, good. It also still works. It's incredibly multiparadigm because it doesn't force you into a way of thinking that's bad for certain domains.
20:29:44
aeth
Of course, on Ada, the point is specifically to not give you that freedom, because if your numerical code is for rockets, you don't want the rocket to explode if the units are wrong.
20:30:30
sukaeto
well, you've got plenty of freedom in Ada. You just have to be judicious about telling the compiler when you want to take liberties and when you want it to complain at you.
20:32:11
sukaeto
people will always ask on #ada things like "why do I get an error when I try to use type X instead of type Y" (where X and Y are two different integer types or some such)
20:32:36
sukaeto
to which the answer is "Why did you define them that way if it wasn't what you wanted, silly?"
20:32:44
pjb
aeth: you keep getting it wrong. Your reals are not modeled by floats. When you say length it means order. < works only on real, not on complex. Writing your code for float is wrong, because there are also ratios! 3/4 is a perfectly good length.
20:33:47
aeth
pjb: Writing your code just for floating-point numbers is wrong, but it's wrong in a very well-studied, well-known way with algorithms written by people smarter than I that you can implement to work with them.
20:34:24
pjb
ok, but you're not writing lisp code then. You might be transfering C or fortran code to lisp.
20:34:56
aeth
pjb: And TAGBDOY will help you manually translate those FORTRAN programs into Lisp, too.
20:35:10
aeth
That's something that a more ideologically pure language would absolutely not give you
20:35:31
aeth
pjb: In practice, though, LOOP with :of-type is what I tend to use when I'm translating numerical stuff into CL, though. Gives you pretty much everything you need.
20:39:42
aeth
pjb: I hope one day someone writes BLAS from scratch with CL (particularly SBCL's optimizations) in mind. Those Fortran to CL translators produce terrible numerical SBCL if you disassemble it (not surprising because they probably predate SBCL and maybe even CMUCL). Handwritten CL can do much better.
20:41:24
aeth
And similarly, I hope that (almost) no one directly uses that library since it would be so incredibly non-idiomatic.
20:45:08
aeth
pjb: Imo, though, for some tasks you have two options: (1) write Fortran or C in your language; or, (2) write FFI code to call into optimized Fortran/C/C++ libraries. And I'm glad CL is in the category that permits option 1 because native libraries with foreign dependencies are often hard to work with and because even just writing C-in-CL looks more idiomatic than wrapping C in CL.
20:46:30
pjb
But if you can solve your problem with symbolic algorithms, it probably be be better than with numeric algorithms. Anyways, for numeric, you won't beat cuda or tesla processors.
20:47:39
aeth
Cuda is for embarrassingly parallel afaik. And even there, sometimes memory latency going CPU to GPU and back will make it slower, again afaik.
20:48:27
aeth
As for symbolic being better, there are two issues with that that I know of. (1) Some things can only be solved numerically (in particular, some differential equations). (2) Even when a symbolic solution can be done, sometimes it's too slow.
20:49:14
aeth
As far as software bloat/expansion goes, eventually every symbolic system evolves to support numerical as well, for those reasons, and possibly some more. I guess Lisp in a sense can be seen as a case of this.
21:04:34
aeth
ralt: Ideally, something like BLAS-on-CL would be written in portable CL as a fallback for architectures/implementations not supported, and use SIMD asm where possible, like SBCL-on-x86-64. So it wouldn't be a simple task.
21:51:37
aeth
mgsk: What are you looking for? For me, I just use an emacs thing (minor mode?) that turns "lambda" when typed into the Greek letter. As long as you don't have a multi-line lambda list (arguments list) it won't mess with indentation in the final source code. And if it is that complicated that you have multiple lines of arguments, it probably shouldn't be a lambda.
21:52:08
aeth
(If it is a multi-line lambda list then the subsequent arguments past the first line will be aligned for one character of the Greek letter when they should be aligned for 6, so that's where the illusion breaks down, by messing up the indentation)
21:53:24
aeth
It will work correctly for single-line lambdas (as long as you don't have a hard line length limit) and multi-line lambdas with single-line lambda lists like (lambda (x y z)\n...)
21:54:46
aeth
I think there's another emacs minor-mode that is more general (i.e. doing more substitutions, not just lambda), but of course that might have more edge cases that will mess up formatting. lambda just has that one (very rare) edge case.
21:56:12
aeth
Well, that's "short lambda" in the literal sense of shortening "lambda". There are other possible short lambdas, like (lambda (x y z) ...) into #[x y z : ...] or something, or maybe (lambda (x) ...) into #[...] where x is now an implicit _
21:57:48
aeth
Of course, substituting "lambda" for "λ" (in several ways, including in the source code or locally in Emacs) gets you most of the way in terms of conciseness, especially once you take into account the extra # most reader macros will add.
21:59:56
aeth
Especially since lambdas are almost always one-liners, or with a newline after the lambda-list (not in the middle of it) so it doesn't affect formatting
22:00:09
mgsk
I suppose it's one of those things that seems nice in theory, and when you have a tonne of throw-away lambdas scattered around. But in practice, it doesn't save you much.
22:02:55
aeth
mgsk: yes, but that should be #λ not λ imo. So now you have #λ(+ _ _) vs. (λ (_) (+ _ _)) and you don't gain much at all and it's super-niche.
22:03:33
madand
Hi all. For 1- or 2-argument lambdas have a look at https://github.com/vseloved/rutils/blob/master/docs/tutorial.md#user-content-readtables
22:03:40
aeth
and really imo it should be #λ((+ _ _)) because most lambda bodies aren't going to be just one expression (usually you can just use #'+ directly if you're in that situation)
22:03:52
Oladon_work
moldybits: And it's not like you're substituting some random character (*coughRubycough*); λ _is_ Lambda.
22:15:33
aeth
Some Lispers don't like the few symbols that are used, like +, *, /, and -, but those are probably justifiable because they're more familiar than the letters and they're easy to type.
22:17:02
aeth
iirc, early Lisp didn't really use any symbols in the identifier names, which is why we have string= for case-sensitive string equality and string-equal for case-insensitive. Backwards compatibility! The old way was case-insensitive and its name remains
22:17:26
aeth
and then you have Scheme which sort of embraces symbols more, which is how you get ? and !