IRC channel logs

2014-08-03.log

back to list of logs

<tuhannetkoirat>taylanub, say, would you happen to know if this is a correct implementation of r6's guard syntax? http://hastebin.com/raw/toweboveda
<tuhannetkoirat>Oh no wait, I see a bug, it's supposed to re-raise the exception if no cond clause matches
<taylanub>tuhannetkoirat: say, why do you keep highlighting random people to ask them questions? :) you should just ask #scheme or so. by the way let me discourage you from using [] so heavily (if you really want to, follow the R6RS guidelines at least), and also from using call/cc, though standard Scheme has nothing better yet
<tuhannetkoirat>taylanub, you seem knowledgeable, in my experience if you randomly ask something no one responds, if you ask someone who is knowledgeable, they tend to, but only later.
<tuhannetkoirat>I could ask in #scheme but truth be told I think people here are nicer for some reason.
<tuhannetkoirat>Also, I consistently use [ ... ] for syntax and ( ... ) for function calls, I find it a better system and a better world starts with yourself eh.
<tuhannetkoirat>It always struck me as odd that syntax and function calls share the same syntax because they're fundamentally different
<taylanub>tuhannetkoirat: I think you should give up with that syntax, it's very unconventional and I don't think it will gain you anything in the long run.
<tuhannetkoirat>At the moment it gives me better syntax highlighting though and the only inconvenience is people not being used to it.
<tuhannetkoirat>Besides, unconventionality stopping people is what stopped people from picking up lisps. I can hardly with a clear conscience tell people they should give S-expressions a try if I would use a form of S-expressions which I consider inferior on an objective level only because it'smore conventional.
<taylanub>tuhannetkoirat: with paredit, () is all you need. having more forms is just distracting. I recommend you to drop the [] style.
<tuhannetkoirat>taylanub, what's paredit?
<tuhannetkoirat>Oh, an emacs mode.
<tuhannetkoirat>No, that actually does not fix the syntax highlighting issue.
<taylanub>your brain will fix that soon enough. :)
<taylanub>I don't really understand what you mean with syntax highlighting issue. how is a mix of [ and ( better for syntax highlighting?
<tuhannetkoirat>Because my syntax highlighting automatically marks the first identifier in ( ... ) as function and in [ ... ] as keyword.
<ijp>if you are already using a syntactic marker for function application vs keyword application, additional highlighting seems redundant
<tuhannetkoirat>Makes it stand out more though.
<tuhannetkoirat>I mean, that 34.3 is a float is evident sans any context, but most highlightersstill mark it differently from "34.3"
<tuhannetkoirat>That S-expressions use the same syntax for special forms and function application, which are fundamentally different and the only way to know what is what is to inspect the bindings is a wart in my opinion.
<tuhannetkoirat>Especially in a language where you are free to add new syntax and functions.
<ijp>if you separate them, you need to add a lot more duplication
<ijp>and, you would need to be able to explicitly test bindings in a macro to see whether they are bound to a macro or a function
<ijp>s/function/non-macro/
<ijp>I don't really know if there is a good writeup about this, but all in all, this is not a serious problem with macros
<tuhannetkoirat>Why do you need to add duplication or test to see whether they are bound to a macro or a function?
<tuhannetkoirat>When you write it you know they are.
<ijp>(define-syntax-rule (foo bar baz) (bar baz))
<ijp>let's ignore that that is a thoroughly unconvincing example for the moment
<ijp>*if* you have two forms of application, then that becomes either a macro with two cases, or one that fails on either macros or non-macros
<ijp>in order to write the two case version, you need to know if bar is a macro or not
<ijp>now imagine a (macro-generating-macro)-generating macro
<ijp>those aren't exactly uncommon
<tuhannetkoirat>You can pass a macro to a macro like that?
<tuhannetkoirat>It always complains about bad syntax when I do that.
<ijp>(define-syntax-rule (foo bar) (bar () 3)) ((foo lambda)) => 3
<tuhannetkoirat>Yeah, seems to work here now with if.
<tuhannetkoirat>Anyway, I don't think you should do that either.
<tuhannetkoirat>Or at least it should need different syntax, because it's something completely unrelated.
<ijp>I think you'll change your tune with experience
<tuhannetkoirat>People always say that, and they are seldom right when they do.
*ijp shrugs
<tuhannetkoirat>Especially when it concerns parents whose children have a different political opinoin.
<ijp>let's not forget, your opinion isn't new. lisp was originally *60 years ago* planned that way
<ijp>but mexprs are long gone
<ijp>come up with a good argument, write your own macro expander, convince people, ... or don't
<tuhannetkoirat>M exprssions are something entire differenyt though
<tuhannetkoirat>M-expressions were laos to be used on function calls, it doesn't separate function calls from syntax at all.
<taylanub>(macro-generating-macro)-generating macro sounds painful :\\
<tuhannetkoirat>I didn't advocate it.
<tuhannetkoirat>Hell, I've also argued against (... ....)
<taylanub>I wasn't talking to you
<tuhannetkoirat>That can become quite painful if it goes multiple levels deep.
<ijp>tuhannetkoirat: M-expressions were to be used as the way of writing lisp functions
<ijp>S-expressions were the symbolic manipulable form of lisp
<tuhannetkoirat>ijp, I know, I just don't see what that has to do with my advocacy of a different syntax for function calls and special forms.
<taylanub>tuhannetkoirat: while learning lisp, did you really think it was difficult to tell apart macro uses from procedure calls, or do you just think it's a neat idea to syntactically separate them?
<ijp>tuhannetkoirat: the point was distinguishing the forms of manipulable lisp exressions was considered inconvenient in practice, and discarded
<ijp>and that is the essential difference you are advocating
*taylanub also often falls for "neat idea" vs. "do we actually need this"
<ijp>and (... ...) is ugly, but it's what we got...
<tuhannetkoirat>taylanub, nothing is difficult, but all bits help. It's also not that hard to read code which is indended quaestionably, but indending it properly helps.
<taylanub>thankfully (... ...) is resolved on the meanwhile by being able to provide an alternative to '...' for your syntax-rules form
<tuhannetkoirat>(.... ...) is more than ugly, it can make code write-only or even unwritable if gone deep enoguh.
<ijp>taylanub: that is the better solution
<tuhannetkoirat>But anyway, the mentality that people have of "I should not do this, because it's unconventional" is exactly what stops people from using Lisp because it doesn't look like mathematical textbook notation and they'd raise the same argumenbts against S-expressions.
<taylanub>tuhannetkoirat: badly indented code messes with your mind while scanning through code; having procedure calls and macro uses look the same doesn't in my experience; instead you memorize the names of macros (and often syntax highlighting makes them apparent too) so it's not an issue while scanning over code
<ijp>stop playing the martyr
<taylanub>tuhannetkoirat: s-expression syntax has enough advantages to make it worth using despite being currently unconventional
<tuhannetkoirat>taylanub, memorizing the name of macros in a language that allows you to ad more, as well as syntax hilighting them does not work..
<taylanub>it makes a rather huge difference. [ vs. ( on the other hand is a rather minor thing
<tuhannetkoirat>taylanub, well I see essentially no downside to using [ ... ] for syntax and only + sides.
<ijp>you are *asserting* that your way is better than the current convention. you are not giving a convincing reason why
<tuhannetkoirat>It is a minor thing, so I don't see the issue.
<taylanub>tuhannetkoirat: it does work; you don't gratiously use macros in lisp code, you create just enough for your domain, and then while reading that program it becomes part of the syntax
<tuhannetkoirat>Whatever small advantage exists from distinguishing a fundamentally different concept, it exists, and I'm not seeing any disadvantage.
<ijp>and it requires complicated macros to be able to distinguish the "types" of their identifiers
<tuhannetkoirat>taylanub, and that would require you to update the syntax highlighing definition for each domain.
<taylanub>being unconventional is a disadvantage though. and I don't believe in the advantage you claim
<taylanub>tuhannetkoirat: yeah, Emacs's file-local variables do that :)
<tuhannetkoirat>ijp, I don't inforce it, it'sjust a style.
<taylanub>you enforce it on those who want to read your code
<ijp>who said anything about enforcing?
<tuhannetkoirat>taylanub, well, I don't believe in the disadvantage of unconventional, the mind adapts in 10 minutes max.
<tuhannetkoirat>I'm fairly certain that if you read in mirror for a day you'll get used to it as well.
<tuhannetkoirat>taylanub, few people do, I only use scheme for shell scripts.
<tuhannetkoirat>And even if they did, that might as well be an argument to never ever write anything in Scheme since the number of people that can comfortably read it is low compared to say Python or C.
<ijp>taylanub: he's not interested, drop it
<tuhannetkoirat>Thank you for reading my mind, you should sell that ability, I hear Uri Geller got rich of it.
<ijp>maybe I will, once I get rid of this stupid moral compass
***tuhannetkoirat is now known as SacreBleu
***SacreBleu is now known as SacreBleu_