libera/#commonlisp - IRC Chatlog
Search
21:00:26
CptKirk
so I made the project, I symlinked to the local-projects folder just as I did before
21:09:31
etimmons
Hmmm, there goes that idea. But I'm surprised ASDF isn't giving you any other information than what you've copied
21:16:05
CptKirk
nice, I got the pattern working for creating a new component and then doing stuff with it
21:49:16
CptKirk
https://common-lisp.net/project/cl-mathstats/documentation/asdf-package/generic-efunction-perform.html
22:01:17
Bike
CptKirk: #1=aoc-15 ... #1# means that the #1# is also aoc-15. like #<ASDF/USER::APRIL-FILE aoc-15 "15.apl">
22:02:27
Bike
what this error means is that asdf expects something to be either a string, a pathname, or a file stream, but you gave it an april-file object instead
22:04:52
CptKirk
https://common-lisp.net/project/cl-mathstats/documentation/asdf-package/class-source--file.html
22:05:24
Bike
okay. so look at this page here. See how, next to name, it says "Accessors: component-name"
22:17:08
CptKirk
I don't know how you're supposed to just know HOW to use something from someone giving you a picture of it
1:15:37
raeda
Is github.com/symbolics on here? I'm doing some statistics work and think Lisp-Stat would be a great way to consolidate existing stats code, but registering a new company with the name Symbolics and requiring a contributor license agreement are worrying signs
1:23:42
hayley
IIRC using the GitHub name Symbolics doesn't really mean you are founding Symbolics 2 (for that see ##symbolics2)
1:26:32
moon-child
they also opened a PR to some random github project purporting to make it work on genera
1:28:09
raeda
I'm sure there aren't any legal problems, it's just weird to see someone setup an account / company with a well known name and then require that open source contributors sign an agreement
1:28:34
raeda
You know, instead of just licensing the project under MIT / BSD / GPL and being done with it
3:05:21
CptKirk
in a macro, how do I define a name which is defined in the macro, but available to users of the macro?
3:06:51
CptKirk
(defmacro my-mac (thing1 thing2 &rest body) `(let ((',@#":available-name ,@body)) ...)
3:06:53
beach
You can introduce any symbol in a macro and it can be used by the caller of the macro. But it is best to avoid that and instead have the caller put a symbol in there, as in WITH-OPEN-FILE for instance.
3:12:16
Bike
this is unrelated, but i wanted to ask before: why (eval '(april:april-load #p"./15.apl")) instead of just (april:april-load #p"./15.apl")
3:13:01
CptKirk
and during development to save double the amount of effort, it is evaluated every time I call into the expression rather than only once at the beginning
3:39:55
Bike
well, for a start you probably want (progn ,@parser), then, because IF doesn't take an indefinitely long sequence of forms
3:42:47
Bike
In the macroexpander you bind the VALUE variable to (if (null parser) sym parser). So if parser is nil, obviously VALUE will be SYM.
3:43:58
Bike
please do multiline pastes in pastebin or something, by the way. i know it's going a bit out of your way, but it clogs up the irc
3:45:07
beach
Yes, I don't think this is the right way to learn a language, but then, learning Common Lisp may not be a goal for CptKirk.
3:46:19
CptKirk
I should clarify, my first exposure to common lisp was 5 years ago now. I've been through a laundry list of books
3:46:46
CptKirk
But all of my time with Common Lisp has been toy problems all done in the repl, using only basic list structures
3:47:30
CptKirk
I'm not claiming expertise or experience, but I wouldn't say I'm starting from the beginning
3:47:53
CptKirk
@beach I know there are a lot of features, but I never did bother with asdf, or importing libraries until this week :/
3:49:19
Bike
i don't mean to sound like an elitist, but repl exercises don't really compare to actually writing programs. I mean, I could probably take a few minutes and write matrix multiplication or something in APL, but i'd hardly say I know it
3:50:05
CptKirk
my use case can maybe elucidate further. I'm professional applicaiton developer in C#/python/angular/react/node with loads of backend tools etc. I was a full time APLer for 2 years, and now host a discord for all array languages. The issue for me is that all the existing FOSS array languages are limited in their library vocabulary, and seeing the
3:50:05
CptKirk
relative maturity of april and the library list of Common Lisp, I'm thinking it would be good to have CL as the driver that talks to the outside world, ffi, libraries, rest, sockets, etc, and APL can do all the pretty logical stuff
3:51:01
CptKirk
which is a very similar pattern to the unix design pattern, using lisp to orchestrate c libraries
3:52:42
CptKirk
from where I'm sitting, I'm not going to learn much more about modern CL reading the classic books. I've learned academic CL, but I have never had an application to build with it, so its all been relatively novice level activities
3:58:23
beach
I really should start my page about Common Lisp book reviews, but I am too busy with other stuff at the moment.
4:03:48
CptKirk
PAIP is much more profesionally written, though the density took me a while to get throught it
4:04:50
dualinverter[m]
I started with Land of Lisp because I had a copy of it lying around; it was a fun read until actual lisp learning started. After a couple of chapters, I found it disorienting.
4:52:23
dieggsy
is there some kind of compilation reader macro shorthand in the style of #+ for if a symbol is unbound
5:23:16
beach
I think what we need is a Common Lisp reference, probably in the form of a web site. I think this could be done by starting with the dpANS and adding more material.
5:28:05
beach
No, that's not good enough. It is a document primarily meant for creators of Common Lisp implementations.
5:29:06
beach
Yes, I saw that. We also have the fantastic work by scymtym to parse the dpANS into various formats.
5:29:22
moon-child
eh, I have no intention of creating a common lisp implementation, and I have always found it adequate. It could perhaps be made more approachable in some respects, but not majorly so
5:30:03
beach
moon-child: OK, example: Read the page on AREF and tell me what happens if you give it an object that is not an array.
5:31:50
specbot
The ``Arguments and Values'' Section of a Dictionary Entry: http://www.lispworks.com/reference/HyperSpec/Body/01_ddc.htm
5:32:27
beach
moon-child: Most newbies, and many experienced Common Lisp programmers don't know that. For example, jmercouris was convinced that an error would be signaled.
6:17:29
moon-child
as far as I know, there is no semantic difference between the way parameters are passed in elisp and cl. This snippet has the same behaviour in both, for instance https://0x0.st/-3ZM.txt
6:55:35
phantomics
Hey moon-child, I figured out what was wrong with {⍵{2÷⍨⍵+⍺÷⍵}⍣≡⍵}12345678 in April
6:56:42
phantomics
Because the 2 is handled as a rational number, the numerator and denominator get huge and the comparison tolerance doesn't work. A consequence of supporting ratios in April
6:58:50
pjb
emacs lisp passes parameters exactly like any other lisp, by value ! Always. CL passes parameters by value too.
6:58:53
moon-child
in raku, rational numbers will get automatically promoted to floats once the numerator/denominator exceed some threshold, unless you explicitly request otherwise. Such behaviour might be worth considering
7:00:20
moon-child
(perhaps the threshold might be when the denominator exceeds ÷⎕ct. That way rational comparisons can always be exact, with no semantic drawbacks)
7:01:32
moon-child
(rather than 'with no semantic drawbacks', I should say 'in a semantically consistent manner'. Except that that is not right...)
7:01:42
beach
moon-child: Also, the "Examples" section of many Common Lisp HyperSpec dictionary entries contains non-conforming code. For a creator of a Common Lisp implementation, it is known that these sections are not normative, but it is embarrassing that newbies are given such examples.
7:05:11
moon-child
beach: fair enough. What you point out about type mismatches I think is the sort of minor augmentation I mentioned would be helpful but not essential. In that it still describes correct usage of the function. But the non-conforming examples are more egregious (and identifying them is far harder to automate!)
7:07:07
beach
Sure, nothing is essential, but I think we can do much better than the Common Lisp HyperSpec in a reference document. For the AREF case, I could see the phrase "If an argument of a type other than an array is given, then the consequences are undefined" explicitly inserted.
7:07:31
beach
And when there is a phrase such as "an error should be signaled", at least making that phrase a link to the meaning of the phrase would be useful.
7:09:08
beach
lisp123: If you read the link you were give, you will see that Common Lisp, just like most modern languages (Haskell excluded) use call by value.
7:10:18
lisp123
beach: the tricky part is this "So, although values are copied before passed to the function, what is copied here is a reference."
7:11:23
beach
lisp123: Call by value just means that arguments are evaluated before a function is called. Nothing else. It says nothing about the nature of those arguments.
7:12:09
moon-child
wiki says 'if [a parameter] is used several times, it is re-evaluated each time it appears'
7:12:13
beach
I am sorry if the C++ people attempt to change established terminology, and I won't grant them that pleasure.
7:12:13
Nilby
The CL spec examples reinforce my belief in thinking for yourself and being skeptical of authority.
7:13:06
hayley
Well, given that evaluation of Haskell code is more or less deterministic, I think avoiding re-evaluation would be an optimization.
7:13:10
beach
lisp123: Again, "pass by value" = "call by value" means that they are evaluated before passed. Nothing else.
7:14:20
beach
lisp123: In all modern languages, when call-by-value is used, a copy of the value is passed, no matter the nature of that value. In certain languages, like C++ and Pascal, and Algol, you can change that by &name, var name, etc.
7:15:42
beach
lisp123: In early implementations of Fortran, this was not the case, so you could say f(1) and f could be defined with parameter x and then x = 2 in the body, and then subsequently, references to 1 would be 2.
7:17:06
lisp123
That link also is very helpful, with a bit more time I should be able to internalise the concepts
7:19:12
moon-child
hayley: no, because if you never evaluate an effectful form, the effect will not happen. For instance, this snippet prints nothing http://ix.io/3z7s
7:20:24
beach
hayley: Call by name, as I recall, is so weird that it was never implemented even in Algol.
7:20:44
hayley
Evaluating an effectful form in Haskell does not cause effects; the effect only occurs if it appears in the value bound to main in Haskell.
7:59:03
beach
I often want to say something like "there is no experiment the application programmer can conduct in order to determine whether some objects are not really references to memory, and are instead encoded in the pointer itself", but...
7:59:55
beach
Now that I think about it, an implementation can decide to "intern" certain numbers, and so the EQ experiment won't work.
8:01:40
beach
pjb: So we can be really nasty to people who try to exploit EQ-ness by having all integers and characters be real references, but we intern, say only odd numbers, and lower-case letters.
8:03:39
beach
OlCe: Indeed. But it is mostly the fact that, whenever I use the term "uniform reference semantics", some people like to point out that the implementation could be optimized in some ways, so that not all objects are references.
8:04:13
beach
Duuqnd: BOotstrap Common Lisp. A project to create a conforming Common Lisp implementation meant only for bootstrapping others.
8:04:35
beach
Duuqnd: It would be the only Common Lisp implementation optimized for maintainability rather than performance.
8:05:28
Duuqnd
I see. I've found two different repos, one is yours and the other is on gitlab. Which one are you referring to (I'd assume it's yours)?
8:05:47
beach
Duuqnd: To me, it is partly an argument against writing Common Lisp implementations in some language other than Common Lisp, for various reasons. Though I know perfectly well that jackdaniel prefer for ECL to be bootstrapped from C for other reasons.
8:06:28
beach
Duuqnd: It is complicated. I started mine, and then pjb started his own, and worked faster for some time, so I gave up. But then pjb got a full-time job...
8:07:51
beach
It is an amusing project to think about, in that it is really hard to avoid thinking in terms of performance.
8:10:34
Duuqnd
That's (a Lisp in C only) certainly useful to have. Is there a reason why ECL doesn't cut it (I'm not very familiar with ECL)?
8:11:16
beach
No, no reason. ECL is fine. But it is less maintainable than it could be, simply because performance is taken into account.
8:12:30
jackdaniel
ecl features two runtimes: one is inside a bytecode vm (and its a very trivial target without many optimizations) and one is compiled to C and then to native
8:13:26
jackdaniel
but then you defeat the purpose of having it as a bootstrapping tool - if you depend on ecl to bootstrap then you may stop at ecl right away
8:14:07
OlCe
jackdaniel: Not necessarily. You can compile an old version once and for all, and use that as bootstrap for newer versions, which are themselves bootstrap for whatever other compiler.
8:14:48
jackdaniel
the point is to have it bootstrappable from C, not from the previous version of the same implementation
8:14:56
beach
OlCe: The use case is what I said. Some Unix distributions want every program to be possible to build using only C.
8:15:48
Nilby
I could just slow down ECL for you? I think it's unlikely, given various examples from history, for a full CL in C to be practically any more maintainable than say ECL.
8:15:58
jackdaniel
my personal opinion is that the problem is already solved having both clisp and ecl, but the argument of better maintainability of bocl as the prime goal is a sound one regardless
8:16:26
OlCe
You are bootstrappable from C if starting with some fixed version (of say, BOCL) pre-compiled to C. You just distribute this C code as the first bootstrap.
8:16:34
jackdaniel
i.e ecl could be stripped from: networking, threading, native compiler, dlopen and various other extensions
8:18:02
jackdaniel
at the cost of performance, features and general usability. so that would be the primary difference between them: bocl would be only for boostrapping (because it would be rather useless in practice due to lack of common extensions); while ecl is meant to be used as the environment to write applications in
8:19:54
Nilby
beach: I think you write more maintaible code than most, but code has a way of developing it's own inertial momentum.
8:20:01
beach
Nilby: Imagine, for instance, every object being heap allocated, with a separate "header", so that CLASS-OF can be the same operation no matter what object type it is.
8:20:20
OlCe
Then, if you not only want a C bootstrap but also that such codeis easy to understand, pre-compiling to C might not be the best option.
8:21:02
beach
OlCe: Again, it also does not qualify as "source code" so can not be used in those Unix distributions.
8:21:59
jackdaniel
OlCe: it is a computer-generated code, so it is not the source, only an intermediate form
8:22:13
beach
No. "source code" is defined to be the "preferred version for modification by maintainers".
8:24:36
OlCe
Duuqnd: I think you could do that legally, but that's another problem (and discussion).
8:24:39
jackdaniel
Duuqnd: of course it could, but foss licenses does not imply such restriction (result of running the program is not the subject of its license)
8:25:15
OlCe
jackdaniel: Yes, this is what I had in mind. ECL runtime can be linked-in statically, but it can dynamically as well I think?
8:25:42
Duuqnd
I was under the impression that a compiler's author couldn't claim any copyright on the code the compiler generates
8:27:45
OlCe
beach: I'm very much interested in bootstrapping techniques, especially from C, but I'm not very sensitive to the "source code" argument.
8:28:32
jackdaniel
the point is that many people are sensitive to it. I believe that debian requires all software to be boostrappable from C (even indirectly, like C -> ECL -> SBCL)
8:29:24
jackdaniel
as of why C has such prominent position as "granted" - perhaps it had its merit 20y ago
8:29:27
OlCe
jackdaniel: But again, this is the case in all proposals above. What is not the case is bootstrap from true "source code", as mentioned by beach.
8:30:21
jackdaniel
I don't think that they would accept a C source code that is transpiled from something else (in a form that is not meant for maintanace)
8:31:24
jackdaniel
like the publisher would not accept a book translation being a result of putting the original in google translate
8:32:47
OlCe
jackdaniel: Especially since the C standard says "undefined behavior" in so many not-that-obvious cases, and most compilers viciously take advantage to optimize code away. And when you start doing nonsense, then it's best to optimize to the point where there is no more program at all.
8:32:50
jackdaniel
beach mentioned that there is a foss definition of the source code, so that would be the criteria for inclusion
8:33:29
OlCe
jackdaniel: I'm not in their heads, so I don't know for sure what they actually want behind this kind of restrictions, but
8:34:05
jackdaniel
as of undefined behavior there are various strategies to take advantage of it - and that depends on the compiler and on the platform
8:34:41
jackdaniel
i.e casting the function pointer to the data pointer makes perfect sense in a system where both are in the same address space, while it should result in an error otherwise
8:35:53
OlCe
jackdaniel: You don't have to update it to new versions of BOCL or others. You just bootstrap the new versions on top of it.
8:36:19
jackdaniel
well I can tell that your mind is set on certain ideas, so I'll leave the discussion at that
8:36:21
OlCe
jackdaniel: If it has flaws, you correct them by hand in C (if readable). In case of a big problem, you transpile again, but this should be fairly rare.
8:38:02
OlCe
jackdaniel: I'm exposing my assumptions and needs, in order to clarify where they differ from what you (and beach) are stating, nothing more. I'm not necessarily "set" as you say. And I perfectly understand and appreciate what you are saying. There is no contradiction.
8:38:44
jackdaniel
I'm not saying that you're not appreciating it. I'm saying that we've exchanged views and there is nothing to add ,)
8:41:14
jackdaniel
OlCe: I'd start here https://en.wikipedia.org/wiki/Source_code and check the [5] annotation regarding fsf definition
8:46:45
OlCe
jackdaniel: Entirely expectable from the FSF. This binds several distributions that absolutely want to abide by this definition and obtain or keep the FSF clearance. It's a problem I personally don't have.
8:48:47
OlCe
And this has not much to do with reproduceability, nor security (directly at least). It's a matter of ideology for those groups.
8:52:17
pjb
beach: it's even worse, since nothing says that implementation defined behavior cannot change over time.
8:53:32
hayley
I disagree that it is "a matter of ideology", given the damn point is to have usable source code.
8:55:23
hayley
Having a solid definition of useful source code is how we don't consider, say, all front-end code to be "free or open source software", or even anything distributed in machine code form only.
8:56:30
jackdaniel
if someone disagrees with the fsf point it is easy to look at it as ideology;; there is nothing wrong with that - opposite stance "I don't care" is also an ideology;; associating negative meaning with the word "ideology" is just a matter of sophistry
8:56:40
pjb
Duuqnd: writing C code is "painful" for anything. Only with time, C programmers become masochistic enough to bear it. Now when you're both a lisper and a C programmer, of course, you don't write the painful C code: you generated it with some lisp code! :-)
8:57:42
hayley
Perhaps I am still eating out of the trash can of ideology, by considering having access to useful source code to a good idea.
8:59:05
pjb
Let's say the difference between bocl and clisp, is that bocl aim to use standard C without using C implementation defined behavior or extensions, so that it can be compiled and run on all platform with a standard C compiler.
8:59:06
jackdaniel
OlCe: code may be readable, but it is also more verbose and harder to change by hand
8:59:07
hayley
OlCe: My non-normative opinion is that the C code produced is reasonable. But I would prefer to modify the Lisp code that it was generated from.
8:59:59
OlCe
hayley: But I'm very much separating the matter of modifying source code and the matter of bootstrapping.
9:00:03
hayley
I think my prior example of "all front-end code" is more illuminating though, particuarly with compressed JavaScript code.