freenode/#lisp - IRC Chatlog
Search
23:44:39
pagnol
I found out about ParentScript only this evening and am amazed that it was made in 2005 apparently, a long time before the js craze took off
23:46:45
aeth
pagnol: Lisp developers see some strange syntax that they're forced to use (JavaScript, HTML, CSS, GLSL, XML, SGML, CSV, JSON, SQL, whatever) and their first instinct is to try to generate it from s-expressions
23:46:55
rme
While Clozure Associates has indeed supported CCL for a very long time, CCL relies on (and needs) contributions and support from its users.
23:49:32
aeth
pagnol: Generating a string or a file from s-expressions is a very simple thing to do.
23:51:54
pansninja
I believe one of the major things that holds lisp back from adoption is not the syntax, but the idiosyncratic documentations.
23:51:59
aeth
pansninja: XML has an ambiguity that s-expressions don't have, probably introduced because of how verbose and annoying XML is
23:52:12
pansninja
I am yet to find a language with more over complicated and poor UX docs than lisp.
23:53:29
pansninja
aeth: But that is not the same thing at all. foo with bar set to baz is not same as a foor with a bar.
23:55:19
Shinmera
The difference with sexprs is that they have no defined structure beyond lists and atoms.
23:55:32
aeth
CL in particular has the plist vs alist issue, most Lisps just have alists, which are harder to write.
23:56:02
aeth
That's probably the most direct comparison, but you don't mix plists and alists in the same data structure afaik
23:56:58
Shinmera
plists and alists are someting made up by people. They're not part of sexpr syntax.
23:57:20
pansninja
Bike: hyperspec is rubbish. Do you really think the image of a script as a button and a wildly complicate layout and flow is good? how?
23:58:21
aeth
The Hyperspec looks like it was designed in 1996, probably because it was (although iirc it was given a slight visual improvement over the 1996 version if you look at the Wayback Machine)
0:01:39
aeth
The HyperSpec could be worse, though. This website is also from 1996: https://www.warnerbros.com/archive/spacejam/movie/jam.htm
0:02:19
pansninja
The point is, that hyperspec sucks in 2018. Not that some websites from 1990s suck more.
0:03:15
aeth
My point is that a web design from 1996 (with the background turned to white and the images very slightly updated iirc) as the official reference isn't going to reflect well on the community. Especially when the competition has websites like this: https://docs.python.org/3/
0:04:06
Xach
People who are used to the spec as it is can access info very quickly, so there's a reduced incentive to change it.
0:04:21
Xach
I am used to it, I like it, and I can find exactly what I need very quickly. So I don't mind the way it is at all.
0:04:48
bms_
There's also a reduced incentive for new people to use it, although I've had no real problem with it.
0:05:39
Xach
I think it takes a special kind of determination to start with something you don't like, learn it well enough to do it better, and then still do it better. There are many opportunities to either peel off or decide it's not bad after all.
0:06:34
Xach
Yes, I think it's pretty important to be able to jump exactly to a definition or chapter.
0:06:41
aeth
Iirc, the HyperSpec has essentially no style. Changing your browser's default font from serif to sans-serif helps make it look more modern
0:10:10
aeth
For more elaborate things, like setting a maximum width, you can use a simple script. One way is through Greasemonkey in Firefox. That's probably a more annoying style issue.
0:11:17
aeth
A lot of modern sites have this issue, though. I guess designers never test their site at 1080p fullscreen
0:14:05
sigjuice
pansninja C-c C-d h takes you right to whatever is under your cursor. and every page has a million cross-references.
0:37:54
sigjuice
aeth https://docs.python.org/3/genindex.html different and http://www.lispworks.com/documentation/HyperSpec/Front/X_Master.htm are not that different
0:51:00
aeth
sigjuice: The HyperSpec is so old that, ironically, its style has (mostly) come back around as long as your web browser defaults to san-serif (which most don't, but it is configurable) instead of serif. The main exceptions are that the search isn't accessible from the page and the navigation is done through GIFs
0:51:37
aeth
Not having a max width is pretty bad, even Python's documentation is basically unreadable with a maximized or fullscreen browser at 1080p
0:53:09
aeth
Another small detail is links are color coded blue and not both color coded and underlined these days.
0:55:56
aeth
One thing almost all of the documentation sites do is make code blocks very distinguishable from body text
1:11:35
rpg
aeth: I'm not sure why designers dropped the underlining -- oftentimes these days links are very hard to find. Sometimes they don't mark them at all and websites are like a point-and-click adventure game...
1:12:24
aeth
It works on Wikipedia. It doesn't work if you don't keep the color system, ideally the exact same one as Wikipedia's
1:16:20
aeth
It's not like the HyperSpec is any better, though. Image links for navigation are bad, especially because they're archaic and so don't stand out
4:11:51
jmercouris
so basically when one sets a minibuffer binding you can just point to a function, and that function will be responsible for invoking the minibuffer
4:12:12
jmercouris
I didn't know about the three semicolons, I was just going off something I googled, but I can change that
4:12:32
jmercouris
Finally, what do you mean by "It is a very bad idea to define functions or macros with names in the keyword package."?
4:20:23
jmercouris
I will be removing this macro anyway, as I think 1. it can be replaced with a function as you said, and 2. I will rewrite most functions to use CPS style so something like (with-minibuffer-input ((valuex (read-from-minibuffer))) (print valuex))
4:21:41
beach
When the reader sees a token that starts with a colon, it creates a symbol in the keyword package.
4:22:51
beach
That is how you can often pass keyword arguments to functions without using package prefixes.
4:25:05
beach
And the reason it is a very bad idea to create functions and macros with such names is that it could then clash with other systems doing the same.
4:25:28
jmercouris
True, or what if I wanted to use a kwarg :input for example, or if anyone else is
4:25:32
beach
Imagine that I want to use your browser at the same time as some editor that also creates a macro named :input, then I can't use both.
4:27:40
jmercouris
Two days ago when writing a macro I was hitting my head against the keyboard for 15 mintues and then I realized I was in the wrong package, and that's why my macro wasn't expanding, so I'll definitely not be forgetting that macros belong to packages anytime soon :D
5:13:57
asarch
One very stupid question about CLOSURES. If I have (I will use square brackets just for annotations): (defparameter *fn* (let ((count 0))[1] (setf count [2] (1+ count[3])))))
5:14:38
asarch
If this was C++ code, then: [1] (let ((let::count 0)), [2] (setf set::count, [3] What count is that?
5:16:00
asarch
The clean code would be: (defparameter *fn* (let ((count 0)) (setf count (1+ count)))))
5:16:26
pillton
Firstly, closures are functions which close over the lexical environment. Your question has nothing to do with functions.
5:17:04
asarch
Sorry, a typo: (defparameter *fn* (let ((count 0)) #'(lambda() (setf count (1+ count)))))
5:19:43
madpengu
pillton: "closures are functions... your question [about closures] has nothing to do with functions"? How?
5:20:27
asarch
From PCL: "However, Common Lisp's lexical variables are lexical variables with a twist, at least compared to the original Algol model."
5:21:07
asarch
"For instance, you can capture the closure created by the previous expression in a global variable like this..."
5:22:17
madpengu
asarch: It doesn't ignores the outside scope, only that it "captures" that current ones. In `(let ((count 0)) #'(lambda() (setf count (1+ count))))` the lambda closes over the count.
5:22:25
jmercouris
asarch: So I can for example say (lambda () *some-global-var*) and *some-global-var* will be "remembered" by the closure
5:23:20
asarch
If this was C, a closure would be a way to "export" variables outside the scope, right?
5:24:14
madpengu
jmercouris: Think of this `(defparameter *MyClosure* (let ((insideOfLet 0)) #'(lambda() (setf insideOfLet (1+ insideOfLet)))))`.
5:24:35
madpengu
There, MyClosure is a reference to the closure which captures the insideOfLet variable.
5:25:37
madpengu
`(defparameter *my-closure* (let ((inside-of-let 0)) #'(lambda() (setf inside-of-let (1+ inside-of-let)))))`
5:26:26
madpengu
`(defparameter *my-closure* (let ((inside-of-let 0)) #'(lambda () (setf inside-of-let (1+ inside-of-let)))))`
5:26:32
asarch
In C++: class point {public: void set_x() {int foo = 5;}}; int main() {point p; int x = 1 + p.foo; return 0} ?
5:27:56
madpengu
beach: Why? Any language that helps you understand a concept is helpful, whatever it is Engrish or Stroustrup++
5:28:29
beach
asarch: In your original code, all three occurrences of COUNT refer to the same variable.
5:29:39
beach
Lexical closures do not exist in C, and (unless they added them recently) not in C++ either, so it is hard to understand Common Lisp by using those languages as examples.
5:30:47
beach
It would be very hard to have full lexical closures in a language without garbage collection.
5:32:01
jmercouris
or rather, how would you know you can release something without a reference count
5:32:07
beach
asarch: Because in the general case, the environment that contains the closed-over variable(s) would have to be allocated on the heap.
5:35:17
madpengu
beach: It is lambda closures, so they don't really escape the current scope and so not true "lexical closures" per se.
5:38:30
beach
So, I see a picture here. C++ programmers are told that they have closures, and they are told that they have garbage collection. That way, they think they have the full power of a language such as Common Lisp. I feel sorry for them.
5:41:41
madpengu
That is all you need to have the full power of a computer, and the full power of what can be done with any language that exists and ever will...
5:43:53
madpengu
asarch: I think one of the big downsides of lisp and relatives are that they're disjoint from reality.
5:44:14
madpengu
The way you reason about problems in lisp is not even remotely similar to what is going on in a modern cpu.
5:44:46
madpengu
beach: I am always new, where ever I am, for that I am not a pond water fish, my friend.
5:45:11
aeth
madpengu: I reason about problems in Lisp by observing the output of (disassemble #'some-function)
5:45:52
madpengu
aeth: You actually do not, you observe the output to reason about how your code works, which only reinforces my point.
5:47:28
aeth
madpengu: But I have the luxury of disassembling a function and if it's clearly wrong, I can use one of a dozen equivalent ways of writing it. Alternatively, disassembly is a good way to see if equivalent ways of writing something truly are equivalent.
5:48:18
madpengu
The idea that you reason about differently in a higher abstraction is given. C is a different abstraction than ASM (though, I always C as just a glorified crss-platform ASM) so there is ought to be a difference in how you think about a problem.
5:48:39
madpengu
Though when you talk lisp, you're not even talking about the same instructions most of the time.
5:51:05
jasom
madpengu: assembly language can support multiple return values; arithmetic operations set cpu flags that are not accessible from C; most assemblies have at least one way of dealing with signed arithmetic overflows ...
5:51:43
madpengu
jasom: Just because you can't reason in C the way you do in ASM doesn't mean that your reason in C isn't mostly directly translated to ASM.
5:52:38
jasom
madpengu: I could show you dozens of examples of C code turning into something very different from what your reasoning would expect
5:54:57
madpengu
But the abstraction between Lisp and CPU is orders of magnitude thicker than C and many C-like languages.
5:55:01
jasom
madpengu: consider a 32-bit machine: int wordFromByte(uint8_t x[4]) { return x[0] <<24 | x[1] << 16 | x[2]<< 8 | x[3]; }
5:56:09
aeth
madpengu: Common Lisp's iterations are, for the most part, ultimately just gotos contained within a tagbody.
5:56:14
jasom
madpengu: how is that a clean mapping to assembly, where it would have a defined result for the straightforward translation to assembly (and not only defined, but the same on all architectures)
5:56:35
borei
seem like setf method is more complecated then i thought initially, and now seems like i missed track to get understanding how does it work
5:56:54
madpengu
jasom: But isn't that undefined by standard? If you don't speak proper C, don't expect proper ASM ;)
5:57:39
borei
i have two classes generic-matrix and matrix-r, first class is parent for the second one
5:57:40
madpengu
Maybe at this point I can't see past the lisp abstraction, but so far, it feels thick, maybe it has to do with it being a managed env.
5:57:50
aeth
An optimized pure FP language or a JIT scripting language has a lot more magic abstraction going on
5:58:19
jmercouris
+1 on what jasom says, C doesn't compile in the way you IMAGINE it would, modern day optimizations are intense
5:59:10
jasom
on several compilers array-referenced loops are faster than pointer-referenced loops because the optimizaer has an easier time of turning it into a decrementer loop
5:59:19
madpengu
jmercouris: Optimizations still do what you expect it to do, maybe in a more efficient way, with lisp, I have no freaking idea what CPU is going to do. Maybe it is just me, maybe it is lisp.
5:59:41
borei
now i need to do setf for elements (not spamming here) - https://pastebin.com/qE26sKMR
5:59:46
rme
It doesn't sound to me like you know CL well enough to make such a judgement or to develop such intuitions.
6:00:28
madpengu
jmercouris: What do you mean? if optimizations doesn't do what I expect them to do, then the compiler is broken.
6:00:34
aeth
madpengu: I'm more confident in what CL is going to do than what an optimized AOT or JIT compiler is going to do because of how sophisticated some of the optimizations in some languages can get.
6:00:47
jmercouris
madpengu: I mean that they are so complex that you will have trouble understanding them completely and all of their behavior
6:01:17
aeth
madpengu: It's actually kind of a bad thing that CLs aren't automagically optimizing everything. Naive CL is going to be slow, and fast CL is probably going to look a lot like C, unless you have a lot of custom macros to abstract.
6:02:05
jmercouris
madpengu: If you claim to be the individual that understands all C compiler optimizations, then you are the first I have ever heard of
6:02:53
jmercouris
Anyways, before making an argument we have to establish some axioms, I don't agree that it is an advantage to understand the underlying assembly
6:03:18
aeth
madpengu: Except C is going to have optimizations that do crazy things and CL that looks a lot like C is going to run like C without all of those crazy optimizations turned on
6:03:39
madpengu
jmercouris: No one claimed that. In fact, if you require an understanding of the mechanics of an abstraction, it is a very bad abstraction.
6:03:48
aeth
SBCL is the fastest CL implementation and I haven't had a WTF moment yet in reading the disassembly.
6:03:56
madpengu
jmercouris: But none the less, not being able to reason about the mechanics of an abstraction also makes it hard to grok.
6:04:11
jasom
madpengu: I am, in fact, assuming I know more about C than you; it's possible I'm wrong...
6:05:16
madpengu
I also don't like how every conversation about lisp or most everything about here is a schlong weaving and measuring contest. lisp is great, but it is not the end of it all, people. Chill.
6:05:44
jmercouris
jasom: it doesn't persist sessions in between open/close, but it's definitely "usable" whatever that means :D
6:06:25
jasom
madpengu: it's not the end of it all. However, that doesn't mean that I agree that the mapping from C to assembly is easy to understand...
6:07:15
borei
btw, i got some first small result with my LISP adventure - implemented multithreaded GLFW-based application (well it's hard to call applcation, but seems like im right direction :-) - sounds strange, some basic lisp aspects still a bit fuzzy.
6:09:16
jasom
madpengu: To a certain regard it is a binary question; IMO any significant code in C is non-trivial to reason about the mapping to assembly
6:09:23
aeth
madpengu: One thing I've noticed about IRC is that if you say something that someone thinks is incorrect, people will line up to try to correct that statement.
6:11:07
jmercouris
madpengu: Don't be mad, it's not worth it to be angry. Getting angry is like drinking posion to punish the person you are having a disagreement with
6:12:02
jasom
There is a subset of C for which the mapping to assembly is quite clear, but the same is true of any lisp descended from cmucl
6:15:08
borei
if i have array of double-float, and im trying to assign integer value to one of the item - im getting error wrong type