libera/#commonlisp - IRC Chatlog
Search
9:44:02
mfiano
It is just anything that accesses, which is also defined to attempting to read or write a place
9:51:43
aeth
getter and/or setter... or in CL-specific terms, reader and/or writer. It's just that the latter is almost always via SETF.
9:53:41
aeth
Where WITH-ACCESSORS won't work is when you need more than one argument, e.g. an AREF, which is definitely an accessor. (* technically, you could use it on an AREF of 0D arrays because those have no index)
10:02:12
mfiano
It's interesting to think about how you can have a SETF-named function or method specialized to a class, that is not considered an accessor (by just returning something irrelevant and not reading from or writing to a place), or to have a class with a slot having only a :reader for its slot specifier, having a true accessor defined with it.
10:42:14
jcowan
fwiw, I do not believe in "the essence of X" arguments where X is a (programmable) programming language. They are like discussions of the essence of humanity: nobody agrees, nor should they.
10:54:27
_death
pve: your assumption was correct, as far as I can tell.. it was meant for standard-objects.. it was invented as part of CLOS (I believe to address some silly criticism).. the replies you got seem to ignore that context though
11:06:09
_death
(in fact symbol-macrolet also came from the CLOS group, but proposed independently of CLOS.. the two CLOS macros with-slots and with-accessors make use of it.. the former macro makes sense to me, but I think the latter one should not have been introduced)
11:16:35
_death
correction: apparently it was not proposed independently, but taken in as part of CLOS
11:30:33
_death
symbol-macrolet started out as a macro with code walking support in PCL and later changed into a special operator
11:33:25
_death
interestingly it was controversial.. one suggested to remove it and make with-slots/with-accessors special operators instead (ouch).. Steele mocked it with a number-macrolet.. lucky for us sanity prevailed
14:25:33
Shinmera
Wrote some beautiful format soup today "~d ~:*~[~;Aeone~:;Aeonen~] ~d ~:*~[~;Jahr~:;Jahre~] ~d ~:*~[~;Monat~:;Monate~] ~d ~:*~[~;Tag~:;Tage~] ~d:~2,'0d:~2,'0d"
14:26:29
jackdaniel
the funny thing is that I don't understand even parts that are meant to be words
14:27:12
Shinmera
Yea it's the german translation of: "~d aeon~:p ~d year~:p ~d month~:p ~d day~:p ~d:~2,'0d:~2,'0d"
14:28:34
jackdaniel
we need to update the standard launching in... 3... 2... 1...; but I'm scared to thing how the extension interface to format would look like
17:24:21
aeth
That would actually be a selling point: if Common Lisp's FORMAT2 *requires* machine learning to function properly. It can be the first programming language with such a feature set.
18:25:55
NotThatRPG
Shinmera: Even English has "formula" and "formulae," "goose" and "geese," etc. English spelling, it transpires, was originally more influenced by history than by pronunciation, and that lingers.
20:19:44
nij-
Has anyone been forced to switch to a lower-level language because runtime performance is critical? Not that I'm facing this issue; I'm just curious to know what are some options in those scenarios.
20:28:55
varjag
i find that if the code makes no use of simd intrinsics or gpu there's hardly ever a need these days
20:31:11
nij-
My friends working for banks use python usually. But when performance is important, they have no choice but to use C++.
20:31:57
pjb
nij-: that has been the case with python. Also for bad support of threads. If I had used CL instead, I wouldn
20:32:40
pjb
nij-: they wouldn't happen as often. Quite heavy duty systems are written in Common Lisp.
20:41:34
Bike
python performance is kind of crap. other dynamic languages can be a lot faster than python. not just lisp.
20:50:40
Bike
cpython baked in some stuff they shouldn't have, and then they got used to just calling out to C to do anything important
20:53:28
gilberth
Are there any language features of Python that make compiling it particularly difficult?
20:58:59
pjb
gilberth: I don't know it enough, but I guess it's OO system is 100% run-time; but in CLOS too, you can change the classes and methods at run-time, so it wouldn't be harder than in lisp, other than in python the OO system is everything.
21:01:22
gilberth
pjb: Ok. Then perhaps they are lazy. I was just curious because I heard that argument that it would be hard not for the first time. And I know next to no Python and thus asked.
21:02:17
Bike
as for the actual question, i genuinely don't think there's much reason to drop into C or whatever for speed, but then i don't do AV processing. memory usage i'd be more worried about. i wouldn't try to run CL on a microprocessor
21:05:38
gilberth
Hmm, but with AV processing the parts of the application that burn 99% of your cycles are very limited. And even C can be too slow when you have a cheap and unsuited MCU and try to do what it barely can in terms of DSP.
21:08:58
gilberth
Otherwise, I am very tired of this kind of "language X faster than language Y" discussions. It rarely comes up that you only need to be fast enough.
21:09:25
Bike
It certainly gets repetitive, especially when we're talking about it divorced from any real use case
21:09:44
gilberth
varjag: 256KB SRAM is common with small MCUs these days. I wait for 1MB or 2MB to be common and then you can deploy CL on an MCU.
21:12:34
gilberth
I once was in the embedded industry. Some time ago. At which you could expect like 16KB SRAM. No way you could run any reasonable application written in Lisp on it. Would I still be in that industry, I'd try to get a reasonable Lisp onto the MCU. 256KB suffices for that, especially when you put your "static space" into flash, which is plenty.
21:14:02
gilberth
varjag: CLISP for instance was initially written for the Atari ST. It was happy with 1MB. It still is with around 2MB, if you really wish and you put some code aside at the flash. If not for the license, I'd start there.
21:14:45
gilberth
varjag: I didn't say Common Lisp. 256KB is plenty for some reasonable Lisp though.
21:18:00
gilberth
What I wanted to say, you could -- and this had been done -- Common Lisp into 1 or 2 MB.
21:24:12
gilberth
varjag: Doesn't change that CLISP still can do with 400KB .mem file, if you wish. On a 32-bit system. And the size of your text segment is not much of a concern as this could be put to flash, which usually is plenty.