freenode/#lisp - IRC Chatlog
Search
14:13:28
sjl_
no one had ops in #clnoobs to combat the spam a while back, so folks moved to a new channel
17:15:33
flip214
sjl_: that problem got solved in the new channel? or should we start keeping a note somewhere?
20:08:11
Godel[m]
Hi, in https://fare.livejournal.com/188429.html, the author claims that `… Racket keeps evolving, and not just "above" the base language, but importantly below. This alone makes it vastly superior to CL …`. What could it mean to evolve below the language? Is he referring to the subsets of racket that exist (functional, lazy)? (I haven't programmed in racket.)
20:14:38
mfiano
Also, he eventually moved to Gerbil Scheme, though I believe he is doing mostly ML these days.
20:15:16
oni-on-ion
Godel[m], perhaps something about racket swapping their guts to chez scheme recently
20:15:43
Godel[m]
Sorry, I don't understand what is runtime type stuff. I haven't dealt with racket at all.
20:22:11
Bike
if you're that concerned you should just ask fare. there's probably an email address on there somewhere.
20:23:46
oni-on-ion
why i say branding is because most/all the other schemes can do the racket things
20:25:46
oni-on-ion
well. parenscript is CL that produces JS. do you want CL to *consume* JS , or something else ?
20:26:45
jmercouris
you can't just translate javascript to CL, there are many semantics to the way javascript does addition, for example
20:27:15
sjl_
https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf is 800+ pages. probably nontrivial.
20:27:21
oni-on-ion
hehe well i wouldnt want to <insert source code> everytime i want to describe it.
20:27:32
fortitude
jmercouris: it's not really an interpreter, but there is http://marijnhaverbeke.nl/cl-javascript/ which might be a starting point
20:28:32
oni-on-ion
well, guile did it. https://www.gnu.org/software/guile/manual/html_node/ECMAScript.html
20:30:55
fortitude
I'd think that trying to preserve all the strange type-conversion stuff would be quite the trick (c.f. all the "what the heck javascript" talks)
20:31:21
jmercouris
I have been thinking a lot about web engines, and I have concluded that the web standard has increased so massively and javascript become so large partly as a way to increase the barrier to entry for new engines
20:32:38
jmercouris
I'm just thinking about all of the components, and what it would take to reasonably fund such a task
20:35:01
Bike
the good thing about it being a virtual machine is that, in theory, you don't need to think like a person to implement it, just follow all the steps stupidly
20:35:23
fortitude
if you're doing a greenfield project, it might be easier to implement webassembly support and take somebody else's javascript-on-WA, assuming that exists
20:35:38
oni-on-ion
if parenscript was written in prolog, one could just swap the args, and get the inverse.
20:41:21
jmercouris
considering; "Embeddable, portable, compact: can run on platforms with 160kB flash and 64kB system RAM"
20:43:27
Bike
it's not how they develop it. if you look at the repo they use separate source files like regular human beings.
20:44:16
Bike
and microsoft's "chakra core" and v8 are both open source, i just don't thinkt hey have ffiable apis
20:45:10
jmercouris
so I guess the minimum budget to develop a new web rendering engine must be at least 500,00.00 USD
20:46:13
Bike
also, that's one designed for low memory usage rather than speed. it probably doesn't jit and stuff.
20:48:25
jmercouris
or rather as an open question, can anyone in the channel explain to me JIT? I don't know much about compilers
20:48:31
White_Flame
of course, that example is in C, and thus has to implement their own GC, while in Lisp you can simply use the native one
20:48:50
White_Flame
I don't think javascript is all _that_ difficult to implement in a naive approach
20:49:09
White_Flame
parsing the source text is probably going to be one of the more finnicky things to do
20:49:50
fortitude
jmercouris: at a very high level, JITing is essentially using an interpreted chunk of code until you've collected som stats about how it is actually being used, then replace it with a compiled version that takes advantage of those stats
20:50:59
White_Flame
you can do things like inline virtual functions, if you can at runtime resolve & assume its type will be consistent
20:51:48
White_Flame
they tradeoff quick-to-start execution in more naive bytecode environments, with slow-to-start optimized machine language outputs
20:51:51
fortitude
jmercouris: the stats you collect allow you to optimize the compiled code for how it's actually being used, instead of how you assume it might be used in some hypothetical future
20:52:16
fortitude
the tradeoff is having to wait a bit before you can actually do that (warmup times turn out to be pretty variable in some systems)
20:52:48
White_Flame
in fact, the entire raison d'état for webasm was to decrease the startup latency of loading & parsing
20:53:10
jmercouris
as the VM runs it makes better and more informed decisions about how to compile snippets?
20:53:39
White_Flame
although it doesn't make its own new auto-classifications; it simply routes the optimization paths the authors have provided
20:53:53
fortitude
thing is the optimizations are local and ephemeral (you don't save them in a "smarter" vm that you use the next time you start your browser up)
20:54:40
White_Flame
and many of the JIT heuristics are incredibly simple, merely figuring out what the actual concrete type of a variable usually is
21:00:35
White_Flame
a histogram is a count of occurrences. X axis is which type a variable happened to be during a pass, Y axis is the count
21:02:28
White_Flame
there's usually a count of times a section of code has been run, and when that hits a threshold, it attempts to optimize it further (and coined the name "hotspot")
21:06:54
White_Flame
the JVM and various JS engines are really fascinating to look into. There's a ton of money & talent thrown at making those faster (regardless of the language quality that runs on them)
21:08:53
jmercouris
what a shame, that money could be spent to heat dumpsters in the NY winters and it would be put to better use
21:34:55
aeth
jmercouris: The real issue is why are those programmers being paid to work on JS engines and not CL.
21:38:28
jmercouris
maybe we should be asking ourselves: "ask not what your programming language of choice can do for you, but what can you do for your programming language of choice"
21:52:24
bexx
i'm doing an assignment in which I need to download the atoms in the max depth of a list to the succesive upper level
21:55:17
no-defun-allowed
could you provide an example? i'm guessing something like ((a b c)) -> (a b c)?
21:58:10
jmercouris
well I would make a tree structure ffrom the list, and then use a depth first search
21:59:08
jmercouris
no-defun-allowed: I think the program needs to be able to accept a generalized input
21:59:59
jmercouris
the easiest way you'll solve this problem is by breaking it down in the way I suggested
22:00:48
jmercouris
performance is not really critical in this type of assignments, more so clarity in understanding what you are doing
22:01:45
jmercouris
bexx: at any rate you will have to traverse the whole structure to find the deepest list
22:02:56
jmercouris
bexx: I'm not really following you, but if you know how to do it now, best of luck!
22:04:41
grewal
jmercouris: My guess is that bexx has already written a flatten-one-level funtion and a get-deepest-leaves funtion. Most *good* teachers tend to walk you through difficult problems
22:05:18
pjb
bexx: deepth of an atom is 0, deepth of a list of atom is 1. deepth of a list of lists of atoms is 2. This is the before deeepest lists you want to process.
22:06:46
pjb
(I take flatten from a library such as com.informatimago.common-lisp.cesarum.list:flatten but you would have to write it for the exercice probably).
22:07:41
pjb
bexx: note that once you have a working solution, you may notice that it is very inefficient, and you might want to optimize it. This will make it more obscure…
22:12:06
jmercouris
the solution is very syntactically simple, but conceptually difficult, in my opinion
22:12:22
pjb
bexx: the thing is that you must write first a working solution. and only once you have a working solution, you should think about optimizing it.
22:13:47
jmercouris
because you will have to traverse the structure a few times, and conceptually it is simpler to traverse a tree
22:14:45
pjb
bexx: see: https://www.informatimago.com/articles/usenet.html#Forms--Lists--Trees--and-Data-Types notably http://groups.google.com/group/comp.lang.lisp/msg/0c66e597e08be90d
22:15:04
grewal
Also it's not so much *making* a tree as it is interpreting the structure as a tree,
22:15:05
jmercouris
bexx: turning a tree into a list and a list into a tree is a function you'd write
22:15:06
pjb
bexx: the problem is indeed not a problem on lists, but of tree. The notion of deepth is a tree notion.
22:15:39
jmercouris
bexx: you could use structs or something to represent nodes, or you could do what pjb says and just treat the list of of lists as a tree
22:15:42
pjb
bexx: but the trick is that there are an infinite numbers of ways to represent trees with lists.
22:16:19
jmercouris
bexx: here is a very short chapter in PCL about treating lists as trees: http://www.gigamonkeys.com/book/beyond-lists-other-uses-for-cons-cells.html
22:16:54
pjb
bexx: so it's a good idea to introduce functional abstration over your representation to clearly manipulate the tree. The function deepth does that. My function flatten-before-deepest doesn't abstract the notion of tree, it's a little magical for this.
22:19:42
grewal
pjb: Why do you keep using the word 'deepth'? Is it a technical term I'm unaware of?
22:23:41
pjb
grewal: (a (b) c) is a tree of deepth 2, with 3 childrens, two leaves a and c, and the subtree of deepth 1 (b).
22:24:39
pjb
bexx: so the magic, is that we don't explicitely say that the list is a representation of a label-less tree node, giving the list of children of the node.
22:25:50
jmercouris
and probably should, because it is unlikely a new user will understand fully/deeply a solution of that nature
22:25:52
grewal
pjb: My question really was 'why use "deepth" instead of "depth"'? And your answer basically is deepth is (1+ depth)?
22:26:18
pjb
grewal: bexx: without the explicit functional abstraction, the magic trick is that I don't show that I've recognized that it was a problem on trees, and given a solution that manipulates implicitely a tree.
22:27:26
jmercouris
bexx: perhaps you'd better spend your time implementing a tree abstraction instead
22:27:59
jmercouris
and part of the exercise is probably for you to understand that nested lists are trees
22:28:26
jmercouris
probably I imagine the nexts lessons will be on homiconicity or something and manipulation of ASTs
22:29:27
grewal
pjb: You usually don't make such mistakes. It's sometimes hard to tell what's an accident and what's intentional
22:32:03
pjb
so in terms of the tree-methods indicated in that usenet post, your trees would be abstracted as: https://pastebin.com/uESF4B2s
22:34:57
sukaeto
Godel[m]: if I were in a snarky mood, my response would be "Has Racket ever been used for anything outside of teaching undergrads how to program?"
22:36:03
pjb
bexx: if you wanted to consider the whole tree, you would have to write it differently.
22:56:38
pjb
bexx: notice that you can easily change the representation of the trees, without changing any of your code. You just need to substitute the set of tree methods in *default-tree-interpretation*
22:57:18
pjb
For example, you could add labels to your tree nodes, or use a representation with CLOS objects for the nodes, etc.
22:59:56
pjb
bexx: notice also that you could just use CLOS and generic methods, but since we are dealing here with interpretations of the same class, namely the CONS class, we would have to wrap our lists in CLOS abstractions. Ie. define different CLOS classes for the different interpretations of our lists. tree-make-tree would return then CLOS instances instead of our lists.