libera/#lisp - IRC Chatlog
Search
16:51:55
jackdaniel
the language specifies semantics of operations. you may either compile the code or interpret it
16:52:19
jackdaniel
common lisp tends to have an excellent compilers, same goes for many scheme implementations
16:52:42
sham1
A language cannot be compiler or interpreted. Those are properties of an implementation of a given language
16:53:43
jackdaniel
sometimes a specification may make writing a compiler harder (or some optimizations impossible), so the language itself is relevant from this point of view
16:55:58
aeth
yeah, a language can be interpreted in the sense that it's nearly impossible (or impossible) to write a compiler due to its language features
16:56:21
aeth
Common Lisp is not such a language, and even in those cases, these days, a lot of "interpreted languages" use JIT compilation for speed
16:57:04
aeth
Not Scheme, either, though, so just about any Lisp that people talk about can be compiled.
16:57:20
White_Flame
terror_terry: is C interpreted or compiled? There are C interpreters around, too
16:57:49
aeth
CL prefers compilation, too, although CLISP compiles to a fairly simple interpreted bytecode in its "compilation" phase.
16:58:11
aeth
And some languages like JavaScript basically need to be JITed if they're compiled at all.
16:59:52
aeth
Common Lisp is fairly close to Python. OOP and stuff. And as long as you get over the fact that Python "lists" are actually just adjustable vectors, you get that fairly easy in Common Lisp (as vectors, not lists, which are linked lists in CL and in most languages)
17:00:24
aeth
Just between vectors, dynamic-style classes (constrast with Java or C++), and hash tables, Common Lisp should be fairly familiar except in syntax.
17:00:33
jackdaniel
I've read that python spec is actually pretty screwed up if we talk about writing compilers
17:01:23
sham1
And Scheme has the nice property of being the language of the SICP, so if you like relatively orthodox CS stuff, it'll do wonders
17:02:15
sham1
Not only have people written compilers in Python and for Python, there's also a compiler for Python in Python (technically RPython but shush(
17:03:43
sham1
Ah yes. So, the SICP as a book really nicely goes into how computer programs are structured (and I suppose how they're to be interpreted, although in this case more in the sense of what we as humans make of it)
17:14:43
Alfr
sham1, you mean, when they are actually working ... and not one of those days where they are demanding more pay and other perks?
17:16:50
Alfr
sham1, (also, unless your programs are human readable, how would you expect those ever getting run? :p)
17:19:11
jackdaniel
I think that people will be hestitant to give you advices, because that's a dangerous gift
17:19:31
jackdaniel
you are on lisp channel, so most probably /think/ that you should learn lisp, then (eventually) C ,)
17:40:57
White_Flame
except that the CPUs still support a C execution model, and the OSes still have C ABIs. It's a low-level detail to learn, but not necessarily a language you need to use
17:43:15
aeth
well, except that C isn't particularly suited for the vector processing that's a massive part of each CPU core now (at least in terms of area)
17:43:46
aeth
C's main remaining use (besides the important projects that still use it) is as an OS/etc. API (even if it's just an API that's actually from something written in something else, like C++)
17:44:05
White_Flame
true, although at an implemenation and ISA level those tend to be cordoned off to their own section
17:44:26
aeth
oh, and the API thing also makes C the most convenient language to write in if you're writing a library to be used by other languages
17:45:13
aeth
Every single programming language in the world has SDL bindings and OpenGL bindings. Probably a bunch of random alternatives to SDL, too.
17:45:15
jackdaniel
also, vendors may provide fine parallelized code with C interface, nobody peeks into the binary
18:02:10
aeth
White_Flame: as far as vector processors being off on their own section, though, that's more against C and C-style thinking, though.
18:02:23
aeth
no reason why you couldn't have something like GLSL on the CPU that has native vector thinking
18:03:20
White_Flame
the core C language doesn't do vector natively (though advanced compilers can infer it from C code), and CPUs have their own separate registers & computational sections for it
18:03:42
White_Flame
while the "main" part of the CPU ISA, registers & state, are all very much C oriented
18:05:11
aeth
yes, so if you take a releasing-this-year 192 core AMD EPYC system that devotes a huge chunk of its space to things like AVX-512... and you only want to use one of those cores, and ignore the vector processor in that core... then, yes, x86-64 is still very much C-oriented. :-p
18:06:12
aeth
So some small fraction of 0.52% of that 2-CPU system (1% if you use the 1-CPU variation and have half the cores, I guess).
18:06:56
jcowan
when I was working for one of the two K companies in the world (K is APL with ASCII functions and nested lists instead of arrays), I once asked why no use was made of the GPU
18:07:16
jcowan
the answer was: "for our scale of data, it takes much too long to get the data into the GPU and out again"
18:10:25
jcowan
Its main speed advantage is its ability to recognize idioms and process them as such, fusing loops and so on.
18:12:15
aeth
I think that's similar to how C++ and Rust and Fortran can beat C in some workloads. They all feature some things that let them make more assumptions about how the program will run, enabling more optimizations than C (although maybe C has various ugly compiler-specific pragmas).
18:12:52
jcowan
Classically Fortran beat C because of its ability to assume there was no aliasing anywhere.
19:30:30
ieure
I have a function which returns a list, and I've declaimed the return type to precisely match what it should return. But when I use LOOP like: (loop for thing in (declaimed-func ...)) the compiler complains: Derived type of (DECLAIMED-FUNC ...) is (DECLAIMED-RETURN-TYPE), conflicting with its asserted type LIST.
19:31:01
ieure
Looks like this is because LOOP expands to: (SB-KERNEL:THE* (LIST :USE-ANNOTATIONS T) (DECLAIMED-FUNC ...))
19:31:55
ieure
(SIMPLE-ARRAY RESOLVEABLE), where the element type is a union: '(OR STRING QURI:URI HTTP:REQUEST TYPE:EVENT)
19:34:34
ieure
Hmmm, it is returning a list, so maybe my type is wrong. Is there a way to say that it's a list containing elements of a type? (LIST RESOLVEABLE) isn't a valie type specifier.
19:35:17
aeth
you can build a struct with typed slots as a "cons" with a car of your type and a cdr of either null or the struct type
19:38:51
aeth
I probably have the syntax off a bit, but something like (defstruct resolvable-cons (car (make-resolvable ...) :type resolvable) (cdr nil :type (or null resolvable-cons)))
19:38:55
ieure
Okay, thank you for the help. Changing to ACROSS compiled, I guess I'll go with that and change the return value to match, since it seems to be the most tractable way forward.
20:12:22
prokhor_
would you mind me asking you some question about reactive databases (playing wth the thought to implement one)?
20:13:06
White_Flame
I mean I can sort of answer, but I'm not sure how much it matches what you're looking for
20:14:26
prokhor_
like: the db does reasoning over its contents: how does it choose what to do (reason about) first?
20:15:32
prokhor_
i am glad that i know somebody who *knows shit*... to make the best out of your answers is my obligation...
20:19:54
prokhor_
well i guess such a system would reason A LOT, given a sufficiently complex& rich content..
20:21:33
prokhor_
if i would choose to do it "update based" (taking updated facts as base point) how would you decide, when to break, do sth else(compute from a different corner)
20:23:42
White_Flame
and since symbolic inference went out of vogue compared to statistical inference, cyc is probably still top dog for features
20:26:37
White_Flame
I haven't used cyc myself, I'm just digging into what I can to learn features & implmentation strategies
20:26:53
White_Flame
however, I do know that it's intended that you hook imperative code into cyc to perform behaviors
20:28:23
prokhor_
may i ask: you told me the last time, you did some work on such databases: what was your topic/goal to think about?
20:30:40
White_Flame
cyc also claims to have included some NN stuff in more recent versions than any of ther publci code releases
20:31:53
prokhor_
i ve got a nl-parser, that gives me every possible parsing as a tree... i want to reason with world/discourse knowledge to filter out the most probable interpretations...
20:32:37
White_Flame
yeah, I've been doing similar searches for nlp, I haven't found anythign useful
20:33:10
White_Flame
there might be something in some ultra complex system, but generally speaking most NLP systems are fixed and don't use their own AI capabilities to affect the grammar understanding itself
20:34:32
White_Flame
the notion of applying AI to the NLP itself is as old as SHRDLU, and not implemented there either ;)
20:34:49
prokhor_
i was thinking of taking sth like this as a base: https://www.airc.aist.go.jp/aitec-icot/ICOT/Museum/IFS/abst/011-J.html
20:35:34
prokhor_
i think, doing sth in parallel is a good aproach, but how do you "coordinate" between the reasoning efforts?
20:36:04
prokhor_
like when do you know, that the reasoning of one process conerns the reasoning of another?
20:38:32
White_Flame
'reasoning' as an abstract notion isn't a first class thing in my system. There are KBs, jobs, tasks, queues, etc
20:38:55
White_Flame
but there's plenty to (try to) read about Cyc's implementation strategies, which is waht I've been slowly trying to get at
20:39:24
prokhor_
how do your systems start a reasoning process(whatever that means in your context)?
20:43:00
prokhor_
how do they know? how do they decide between new facts from input& such the reasoner has added?