IRC channel logs
2016-08-30.log
back to list of logs
<sapientech>wingo: alezost paroneayea thanks for the infos. yeah it would be nice to have something other than autotools. <civodul>anyone written a Guile plugin for Emacs 25? :-) <amz3>paroneayea: the black theme is difficult to read IMO <amz3>paroneayea: I'll fix that later <paroneayea>and=> combined with assoc-ref and cut is a great way to traverse down an alist of alists <paroneayea>assuming you don't have any #f in there as values, that is :) <paroneayea>doesn't need full on css reading and manipulation <zv>so srfi-26 says that it's not currying <zv>what exactly makes `cut` different from currying? <ijp>currying is representing a function that takes n arguments in terms of functions that only take one argument <ijp>this is apparently very difficult to understand as everyone from joe php programmer up to scala doesn't understand it <ijp>and odersky should know better <zv>but what exactly makes (cut fn 1 <>) any differerent than ((curry fn) 1) <ijp>currying implies the ability to partially evaluate, but partial evaluation is not currying <paroneayea>civodul: wow, I think I heard of DSSSL and how it was maybe a contender along with HTML, but CSS won <paroneayea>but I never realized it was sexp and looked so much like scheme <zv>ijp, ok, so then (cut fn <>) then <zv>whoa, i hadn't heard of this dsssl think before <ijp>take fn to be (lambda (a b c) c) <ijp>(cut fn <>) = (lambda (x) (fn x)) <ijp>(curry fn) = (lambda (a) (lambda (b) (lambda (c) c))) <ijp>the former will always give an arity error, the latter will return a function that returns a fucntion <ijp>assuming someone implemented curry currently, which they inevitably didn't <zv>it sounds to me like its pretty safe to garbage collect the concept of currying and overwrite it with partial application <ijp>the two are completely different concepts <ijp>not orthogonal, since currying implies partial evaluation, but you can certainly have partial evaluation without currying <zv>if one is a subset of the other, i think there is a widely held logical principle that suggests that they are not "completely different concepts" <zv>but i jest, you are a good teacher ijp <ijp>I wouldn't worry too much, give it forty years and everyone who cares about the difference will die off <paroneayea>civodul: I'm still not sure having lambdas in something css-like would have been a good idea though! <paroneayea>though I guess we effectively have people doing styling via js now <dsmith-work>dsssl is actually a purely functional dialect of scheme, iirc <paroneayea>ACTION just got signed cookie based sessions working in pubstrate \\o/ <wingo>so i had a thought re: read and such <wingo>you are sending signed cookies to the client, right? <wingo>so you'll never `read' an s-expression that wasn't sent by you at some time in the past <wingo>so if you never send a #. or similar expression, you'll never see one <wingo>and so it's safe to just (call-with-input-string str read) <wingo>provided you have verified the signature of course <paroneayea>but! there have been other cases where I've wondered <ijp>signing a cookie is a perfectly silly idea, you either eat the signature, or can't eat the cookie at all <wingo>and we certainly need to fix the (((( issue :P <paroneayea>and the http REST api case is one where you don't have that samecase <wingo>civodul: we found this last night: (call-with-input-string (make-string 200000 #\\() read) -> segfault <ijp>I'll never get used to #\\() <wingo>so we just need to insert the right stack checks <civodul>or transform it into a heap exhaustion ;-) <wingo>heh to do that, we should rewrite to scheme :) <civodul>that'd automize the transformation indeed :-) <wingo>surely there is a way to write in scheme, generate c from the scheme for the boot, and otherwise use the scheme <paroneayea>basically "how many ways can we make (read) unsafe to arbitrary input?" <wingo>hey i'm so excited you're speaking at the scheme workshop! that sounds like fun especially with cufp & icfp <zv>ijp i feel a bit bad asking you since you already answer so many dumb questions, so dont feel obligated to look this over but i've asked tons of other people this question without any sign of success: phillip wadler says here in like the first 10 minutes: https://www.youtube.com/watch?v=IOiZatlZtGU that you can get the steps of a 'proof' builder out of a normal 'modens ponens' deductive system. sicp asks you <zv>to build one of these and I was wondering if anyone knew how I would go about keeping track of the rules applied *AND* their unification the the EXACT order in which they are needed? (and if that would satisfy any meaningful definition of 'proof synthesis') <zv>davexunit: is it really? <davexunit>zv: it's a joke about civodul giving two talks at conferences in japan soon <wingo>civodul: wdyt about fdes finalizers in (ice-9 fdes-finalizers) ? i don't know where else to put them <zv>i hear its not that cool <ijp>used to be that everything was smaller in japan, how things have changed <zv>ijp are they now bigger? <ijp>no, they are the same size as everywhere else <ijp>I don't really understand your question <OrangeShark>isn't there some pretty well-known lispers in Japan? <OrangeShark>I know there is this one guy who wrote a bunch of Common Lisp libraries and software <ijp>I'm not sure if it's simple or not, I feel like it should be <ijp>I mean, stuff like the SICP logic language / prolog / etc. are really just doing backtracking, and your rules would just correspond to constructors in the datatype of proofs <ijp>hmm, no, that's too simple <ijp>or rather, it would duplicate work <ijp>or would it? dunno, I'd need to think about it <ijp>incidentally he gives another talk "category theory for the working hacker" which is just a worse version of the same talk by Erik Meijer <sapientech>well its a little frustrating getting autoconf to work, getting an error where im copying the same twice, not sure if any of yall ran into that problem <sapientech>anyway, based on the above messages, people dont seem to hot on having autotools as the default way to package pure guile projects, so i thought this could be an opportunity figure out an alternative <sapientech>random-nick: know if any other scheme implementations have one? i believe chicken does <sapientech>or at least some canonical way to declare packages <wingo>there is room for a solution but finding a good one takes taste and luck :) <wingo>looking at other scheme systems is a good idea tho! <daviid>sapientech: do you have a repo somewhere we could look and try to help? the first attempt to 'autotoolchain' is always difficult, but then things get easier ... <sapientech>it always fails when i do: ./bootstrap && ./configure && make && make install <sapientech>but works when i do ./bootstrap && ./configure && make install <daviid>sapientech: ok, i'll try to look at it later today, i'll have to go afk soon <sapientech>the issue, however, is that i am having issues making it work with guix <sapientech>when i try to build through guix, i get the same error as above, even when i remove make, and just call make install <daviid>sapientech: but wait, it is normal you have to run ./bootstrap <daviid>sapientech: hum, sorry i did miss read, i'll look into it later <daviid>sapientech: you should use guile.m4 macros in your configure.ac file instead of 'guilemoduledir="${datarootdir}/guile/site/2.0"' <daviid>sapientech: but here, jyust did ./bootstrap;./configure --prefix=...;make and i see scheme warnings, but no autool bugs <sapientech>daviid: btw used that line from guix's configure.ac <OrangeShark>this will get you stuff like GUILE_EFFECTIVE_VERSION <sapientech>OrangeShark: cool, thanks i was using GUILE_PKG earlier but was causing parse issues (was using the configure.ac in haunt)