tag:blogger.com,1999:blog-5722310642266356003.comments2024-01-07T23:21:32.676+01:00The Axis of EvalUnknownnoreply@blogger.comBlogger569125tag:blogger.com,1999:blog-5722310642266356003.post-22491794096050733492023-08-29T19:41:50.457+02:002023-08-29T19:41:50.457+02:00I come from the far off yeah of 2023, where we do ...I come from the far off yeah of 2023, where we do this in Clojure and have paredit implementations that are perfectly capable of handling different delimiters.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-24139954146190485102019-08-08T04:24:23.346+02:002019-08-08T04:24:23.346+02:00Lisp invented destructuring-bind and pattern match...Lisp invented destructuring-bind and pattern matching, yet, everyone goes on using car/cdr... which unfortunately can not be made parallel... Also John Mcarthy himself said that he wanted the let syntax to be like Clojure's. aoeu256https://www.blogger.com/profile/16123595678632117502noreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-8330112619348863222019-08-04T20:19:28.760+02:002019-08-04T20:19:28.760+02:00Interesting. So in a condition system, two things ...Interesting. So in a condition system, two things are needed.<br />Some code in the "handle" block of the caller:<br /> throw new UseValRestart("the default value");<br />And some code in the "resume catch" block of the callee:<br /> return r.getVal();<br /><br />It seems to me that conditions can be trivially implemented in any language that only supports non-resumable exceptions.<br /><br />Instead of the "handle" block in the caller, we'd write this:<br /> the_global_function = function() { return "the default value"; }<br />And in the callee, we'd just replace the<br /> throw new NoValException();<br />by<br /> if (the_global_function == null)<br /> throw new NoValException();<br /> else<br /> return the_global_function();<br /><br />Of course, in the general case it's not that simple. If we want to support multiple handlers among the call stack, we'd need the_global_function to be a stack of functions instead. And we need to set the_global_function back to null when the caller returns.<br />The value of conditions seems to be that they make invisible this global function circuitry.<br /><br />But would we often need such a system? Sometimes we don't need multiple handlers. In that case, the "no condition" rewritten code seems overall simpler and shorter.<br />And maybe in some cases we could even just pass the function as a parameter instead of as a global.<br />In other cases yet, we could simplify further and eliminate the "if (the_global_function == null)", or move it into the handler function.<br /><br />In conclusion, from reading only this post, I'm not really convinced how useful conditions are in practice, compared to just non-resumable exceptions.<br /><br />It also seems that the API of every function would be more complex in a language with conditions.<br />In a language with exceptions, I have to know what exceptions are thrown by what I call.<br />In a language with conditions, I have to know what exceptions are thrown, and whether they are resumable, and in how many ways I can resume them, and what exceptions I need to throw to make them resume.vzqhttps://www.blogger.com/profile/11555805438621899452noreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-75975913361389102572019-06-07T02:00:19.983+02:002019-06-07T02:00:19.983+02:00kbob, you're unlikely to get a chance to resta...kbob, you're unlikely to get a chance to restart from an exception in Scheme. MIT Scheme is the only Scheme variant that supports non-unwinding exceptions and restarts, that I'm aware of.<br /><br />You can kind of emulate unwinding exceptions by using continuations, but they're not the same thing, since the stack unwinds, and then you UN-unwind the stack by calling the continuation. When the stack unwinds, any DYNAMIC-WIND unwind handlers get called, which can lead to the state being different when you call the continuation than it was when the exception was thrown.<br /><br />In Common Lisp, conditions can be handled before UNWIND-PROTECT cleanup forms get executed.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-22292821672697085272016-05-20T05:33:06.992+02:002016-05-20T05:33:06.992+02:00You might find this relevant: https://news.ycombin...You might find this relevant: https://news.ycombinator.com/item?id=11223697<br /><br />It takes this thinking down to each character typed. Happy to see other people having the same thoughts :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-4245375021908484712016-04-03T19:36:56.332+02:002016-04-03T19:36:56.332+02:00This talk is not about if eval is needed or not in...This talk is not about if eval is needed or not in env. Clojure is lisp and has homoiconicity. Data are code and code are data. Not allowing to execute what you have just build in language (or during slurping input from other system) is breaking the homoiconicity. Just tell Rich Hickey how he has castrated it's baby and I bet he will fix that.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-51822618895731593852016-01-29T22:56:01.181+01:002016-01-29T22:56:01.181+01:00Here's my take on the motivations for Hoon (no...Here's my take on the motivations for Hoon (not necessarily the rest of Urbit). I don't know Hoon, although i'm learning it, so this may be wrong.<br /><br />The reason for Hoon is to have a language with the properties: (a) based on a core with a tiny spec (Nock) (because Urbit hot-patches itself with code over the network, so in order to specify Urbit's network protocol completely, the complete operational semantics of Nock must be included in the protocol spec, and so an extremely small spec was desired), (b) the core can 'eval' without overhead (because hot-patching), (c) purely functional, (d) does not (natively) support cyclic data (because cyclic data is harder to serialize), (e) good at validating untyped data; defining a custom type in Hoon is the same as defining a validation/normalization function that attempts to cast untyped data into the type.<br /><br />About Nock: Nock is a purely functional 'assembly language'. One of its design goals is to have an extremely short specification; its spec fits on one page. Nock may be seen as elaboration of SK combinator calculus in the same way that traditional assembly language may be seen as an elaboration of Turing machines. Nock has two data types (integers and binary trees) and 7 primitive instructions: S and K from SK combinator calculus; integer successor; cons; test for structural equality; test whether a value is an integer or a binary tree; and selection of one node from out of a binary tree (given the tree and an address).<br /><br />Hoon is intended to be the 'C' to Nock's 'assembly language'. It is supposed to be a thin layer above Nock, 'a glorified macro assembler' rather than a fundamentally higher level of abstraction. So Hoon is an answer to the question "In a world where our machine model was SK combinator calculus instead of Turing machines, what would be the analog of C?". <br /><br />As for the crazy names: orthogonal to the above, the creator of Hoon made a design choice w/r/t naming things. He believes that (a) it's confusing to have two things which are close but not quite the same be given the same name; and (b) the analogs to Turing-machine-land programming constructs in SK-combinator-machine-land tend to be close but not quite the same; therefore he invents an entirely new vocabulary for Hoon. Furthermore, he thinks (c) names in programming languages should be short, one syllable, natural language words; and (d) it's unimportant if a newbie has to memorize many such words; therefore the new vocabulary has words like 'arm', 'leg', 'kelp', rather than longer descriptive names. Furthermore, he chose to (e) reject alphanumeric keywords; Hoon's built-in keywords should all be punctuation. The creator claims that these design choices are validated by the evidence that he's talked to a number of people who have learned Hoon, and who after learning it, agree that it is neither crazy nor difficult.<br /><br />My personal opinion is that Nock is beautiful, and I'm interested in learning Hoon just to see what 'the C of combinator calculus' might look like. I'm not (yet) a fan of the naming choices in Hoon.<br />Bayle Shankshttp://bayleshanks.comnoreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-86882857735233486532015-12-25T15:00:24.223+01:002015-12-25T15:00:24.223+01:00Lisp is an end [in] itself because of macros i.e.,...Lisp is an end [in] itself because of macros i.e., code rewriting. No other [kind] of language has such an extensive, essential, defining feature: easy, straightforward code-rewriting as a foundational feature of the language. Yes, you can do metaprogramming in C++, but templates were not designed for metaprogramming; instead, metaprogramming was discovered to be possible after templates were designed, and only by a twisted exercise in endocrinology. Etc. A Breaking Changehttps://www.blogger.com/profile/00115031720080635093noreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-16454772406368297202015-08-17T20:20:53.736+02:002015-08-17T20:20:53.736+02:00I invented a variant of this some years back in wh...I invented a variant of this some years back in which (make-type) does not return a first-class object, but returns a tagger, an untagger, a predicate (which serves the purpose of the first-class object, and eliminates type-of), and a thunk which when called is the same as calling (make-type) except that the predicate it returns falls back to the third value returned by this call, thus being in effect a subtype.John Cowanhttps://www.blogger.com/profile/11452247999156925669noreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-22868967621547824782015-08-03T17:04:53.344+02:002015-08-03T17:04:53.344+02:00Leveraging HTTP protocol for RDP is something I...Leveraging HTTP protocol for RDP is something I've planned to do. Though, my work on RDP was tabled to work on other aspects of my Awelon project. My sketched designs for RDP over HTTP had pushed differences into the URL query string. The reply could include information such as stability of the signal and a URL to query again in the near future. <br /><br />I was planning to leverage this together with exponential decay, i.e. such that users can examine the deep past (albeit at diminishing detail).<br /><br />With the e-tag approach, I'd recommend use of `accept` (on GET) and `content-type` fields (on the result) to indicate diffs vs. whole-value signals.dmbarbourhttps://www.blogger.com/profile/12370605342201490009noreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-13652041181032213212015-08-02T17:21:25.339+02:002015-08-02T17:21:25.339+02:00Looks good. 304 should be used instead of 204 in t...Looks good. 304 should be used instead of 204 in that case though. RFC 7232 may provide some food for thought. Daniel Yokomizohttps://www.blogger.com/profile/12528969103424062002noreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-13627596875158007172015-07-27T19:08:33.177+02:002015-07-27T19:08:33.177+02:00A purely functional base language (like Nock) and ...A purely functional base language (like Nock) and use of 'jets' to recognize and accelerate common functions is a fine idea. It really allows low level use of a purely functional language. I was planning something similar with my Awelon Bytecode (ABC) even before reading about Urbit, and I was happy to see the idea validated in practice.<br /><br />Not sure how I feel about Hoon. Seems difficult to judge something like that without really diving in and trying it.dmbarbourhttps://www.blogger.com/profile/12370605342201490009noreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-719432713727640022015-07-21T18:06:35.877+02:002015-07-21T18:06:35.877+02:00Philip Monk sent the following email which clarifi...Philip Monk sent the following email which clarifies some things (quoted with permission):<br /><br /><i>It's important to emphasize that anonymity is absolutely possible: just create your own self-signed comet. We're definitely not out to destroy anonymity; on the contrary, there's all kinds of great use cases for it. The thing about anonymous machines, though, is that they cannot have a default positive reputation. You shouldn't trust anything coming from someone anonymous without some amount of crypto establishing their identity. What we provide is a way to be *not* anonymous, which is hard to do in the current unix/internet system. On the internet, every app has its own concept of identity and reputation, and these don't tie together at all. Unix usernames, ip addresses, dns names, facebook accounts, reddit handles -- these are all identities, and they're almost totally unconnected. In urbit, identity is a unified concept built into the os and network.<br /><br />As for hoon, I was definitely initially put off by it as well. It turns out, though, that after you get past the (admittedly significant) apparent complexity, it's an eminently practical langauge, and a real joy to use. I've never used a functional programming language -- even an impure one -- that felt so much like an imperative one. hoon is what you get when a systems guy needs a purely functional programming language to build an operating system. It's a lot like Haskell without the math, and without the unix stuff.<br /><br />Since hoon is homoiconic, the syntax isn't that bad. There's a fair number of gotchas that should be smoothed out, but it's all pretty localized. There may be cases where you're not sure what it's going to do, but it's pretty rare for their to be a case where you think it's going to do one thing and it does another. We do apologize for a lot of the nonsense names. Humans are actually quite good at associative memory, and you learn them pretty quickly, but in user-level code we use long-form descriptive names. It's only in the kernel that we use the lapidary style. Also, we generally use only about 30 or so of the runes, and you stop noticing them pretty quickly. It's a rather pleasant experience when punctuation is structure and alphabetic text is content.<br /><br />The jet system is unique, for sure, but it actually buys you quite a lot. In some sense, jets are just a part of a "sufficiently smart" interpreter. Most of the jets are for fairly low-level operations -- from bit manipulations to fold to map operations. Nothing in the kernel modules, for example, is jetted. What jets buy you is simplicity. You don't ever have to actually break the abstraction, so unless you have a malfunctioning jet you can pretend you're doing it all in pure nock. Without jets you can't use something as simple as nock/hoon to build something as complex and practical as urbit.<br /><br />The claim that urbit is designed to disempower users is completely backwards, and can only be attributed to gossip passed around by people who never gave a serious attempt to understand the system. On the current SAAS-dominated internet, we are all digital serfs to whoever we have an account with. If some service decides to shut down your account -- or, indeed, their whole service -- then all your data is gone and you can't use it anymore. Megacorps mine and sell our personal data to advertisers as their business model. In a personal cloud computer like urbit, the user controls their own online presence (including their identity), and nobody can take that away from them.</i>Manuel Simonihttps://www.blogger.com/profile/07840673741485280526noreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-37536531266805817092015-06-17T16:06:39.432+02:002015-06-17T16:06:39.432+02:00Reading a blurb on Alan Kay's idea to create w...Reading a blurb on Alan Kay's idea to create whole computer system, including windowing system, menus, gui with layout, publishing etc in 20,000 lines of code mentioned that it uses reactive programming (and constraint based layout). But it was mentioned that a tick based model for updates was chosen because that apparently simplifies some problems. That is to say, it's organized like a video game where time is measured in discrete animation steps.<br /><br />I'd like to see how that solves problems and how one rolls that in.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-18822839012097992772015-06-17T10:12:42.265+02:002015-06-17T10:12:42.265+02:00Patrick, yes that absolutely sounds like something...Patrick, yes that absolutely sounds like something RDP can model this way.<br /><br />Usually, signals are actually accessed by means of behaviors, analogously to how a filesystem is accessed by means of a file server in Plan 9.<br /><br />So there could be a bCurrentMenuSelection behavior that, when there is a demand (input signal) on it, responds with a dynamically updating output signal containing the currently selected item. The input signal on bCurrentMenuSelection could simply be an empty/null/unit signal, indicating the time and duration of your (or another component's) interest in the current selection.<br /><br />The main behavior of an RDP app is activated by supplying it with an empty demand, and usually its output signal is ignored (if the app is just run for effect, such as displaying a GUI). This initial empty main demand is then passed around inside the application (duplicated with bdup into a product signal, see Sirea README) to activate its sub-behaviors. <br /><br />It's also possible to dynamically reconfigure the behavior network at runtime. Here's an example of how that could work from David: https://groups.google.com/forum/#!msg/reactive-demand/C_0TJjTQkzo/z5VEoSJZePkJManuel Simonihttps://www.blogger.com/profile/07840673741485280526noreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-87093553219637020492015-06-16T22:27:36.248+02:002015-06-16T22:27:36.248+02:00One thing I am not clear about is how dynamic the ...One thing I am not clear about is how dynamic the signals system can be. For example, can I define a "current menu selection" signal and as I move the pointer over a menu (list of items), the item under the point at any given time is the value of a "current menu selection" signal? (if that the proper terminology?)patrickdloganhttps://www.blogger.com/profile/09030151653908100586noreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-90180521683404107652015-06-15T21:42:26.674+02:002015-06-15T21:42:26.674+02:00Dobes, in the above example, sigIn is the demand t...Dobes, in the above example, sigIn is the demand that causes myBehavior to compute an output on sigOut.Manuel Simonihttps://www.blogger.com/profile/07840673741485280526noreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-69494934477571969122015-06-15T21:16:02.423+02:002015-06-15T21:16:02.423+02:00This is great I am also trying to decode RDP. I t...This is great I am also trying to decode RDP. I thought in RDP the downstream behaviors or signals were supposed to push a parameter upstream as well. Otherwise we are missing the "demand" part. Am I right here? Have you thought about how that would work in "bucky"?Dobeshttps://www.blogger.com/profile/09392777569321223496noreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-76870752671790911382015-06-15T20:59:34.364+02:002015-06-15T20:59:34.364+02:00Reminds me of Forth.Reminds me of Forth.Lars Brinkhoffnoreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-48448755912300149692015-02-02T01:12:07.203+01:002015-02-02T01:12:07.203+01:00It's a shame this has disappeared. There is s...It's a shame this has disappeared. There is so much drivel spoken about what is such a simple and useful concept. Was it the terribly expressed attempts at analogies that enraged you? Or the mechanism itself? Huge sympathy for the former, bemused by the latter.Anonymoushttps://www.blogger.com/profile/01855998205950703652noreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-79254709000730400862015-01-30T19:19:38.856+01:002015-01-30T19:19:38.856+01:00I'm late for this party.
The action already i...I'm late for this party.<br /><br />The action already is mostly on the client side except in those cases where you really don't want the client to have access to the information or process being run. Example: casino games.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-17940906431380477382014-08-27T18:27:30.016+02:002014-08-27T18:27:30.016+02:00@Nightstudies, there are (at least) two different ...@Nightstudies, there are (at least) two different meanings of "monad" in current use in math. (It seems to me a big chunk of the study of mathematics is a specialized branch of linguistics; but I digress.) A techreport I wrote about the Haskell-related kind of monads some time back: <a href="ftp://ftp.cs.wpi.edu/pub/techreports/pdf/03-21.pdf" rel="nofollow">pdf</a>.John Shutthttps://www.blogger.com/profile/00041398073010099077noreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-4573921185473513072014-08-24T00:09:42.285+02:002014-08-24T00:09:42.285+02:00I have to admit that I lack any experience in Hask...I have to admit that I lack any experience in Haskell and I came in after the original post was deleted but I'll mention a few ideas I have on monads:<br /><br />1) they're necessary in Haskell for sequences of commands - lazy eval needs a way to give commands a dependency on their antecedent. It needs a root to the program.<br />2) they've been described as a programmable ";" (C end of statement op) - and that is very useful. The List monad gives an example of how far that can be pushed... Though there may be a better way to do this. I'm interesting in metaprogramming that is more explicitely programming and more expressive than type matching schemes even with very powerful types... <br />3) The fact that it's called a "monad" seems a bit silly. A monad is a binary operation that has an identity element. If you have a way of processing lists of statements, then if there was no "identity" element to start with, the loop which processes statements would have to be built with a few checks to handle the first statement differently than others.. Taking an "if" out of a loop hardly seems like the essense of what you're doing here. Nightstudiesnoreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-47610689539931244312014-07-13T06:24:21.321+02:002014-07-13T06:24:21.321+02:00Drat, I've missed the rant. Well, I can always...Drat, I've missed the rant. Well, I can always add thoughts to the next one:<br /><br />I've programmed in both dynamically- and statically-typed languages at length (starting w/ Scheme at the impressionable age of 10, keep that in mind).<br /><br />A Java-esque type system (even discounting workarounds for initial design flaws) is in the uncanny valley of pain and uselessness. We shouldn't even think about these systems in language design, except to laugh at the flaws and ensure we never make the same mistakes.<br /><br />The Haskell type system is expressive enough for roughly 95% of the code I write. There are definitely some flaws, about a third of which comes from using typeclasses instead of ML-style modules, another third of which is solved by the rank-n type extension, and the final third I would normally implement in a dynamic type system, except that usually some overly-clever person has made a library to hide the mess (looking at you, Data.Vault).<br /><br />That said, I rarely jump on metaprogramming in my code, but if that's your cup of tea, then I would go for a dynamic language in a heartbeat. I understand Template Haskell is cool, but the error messages are crap and it suffers to massive extent by not being homoiconic,<br /><br />The thing that draws me to system-F derivatives is that I can explicitly write down a ton of architecture in the types and have it checked without wasting time writing additional testing code. This gets me two things: 1) I can examine how the entire system fits together without writing the entire implementation, and 2) I can rip out the architecture and replace it with a different one with astonishing ease.<br /><br />In contrast, in a dynamically-typed language, I need to have the entire system architecture built up front. If I make a mistake, the language doesn't help me, so it's best to hand-check it up front, but the more mistakes I want to catch, the more painstaking the process. This point was driven home for me recently when I attempted to build a web framework, at first in a dynamic language. As my requirements came into better focus, it became apparent that a rewrite was more economical than a refactor, and more insight was likely on the way, so I ported to a static language.<br /><br />Dynamically-typed languages are necessary for those coding edge-cases, but for average code, odd as it sounds, type systems benefit experimentation and evolution. That said, this is all just my personal feeling based on experience. Perhaps it's just that I tend to think top-down, or just my level of sloppiness. In any case, it's not the blub paradox, since not only use lisps, I'm writing one (based on Kernel and your xons idea among other things, btw, both of which I found off your blog, so thanks).<br /><br />Monads aren't inherently a problem for a lazy language like Haskell. The problem is that they're explained very poorly, so it takes too damn long to grok them (months >.<). I've seen considered opinions that monads aren't good in ML derivatives, but haven't examined it myself. The idea that "Monads are the One True Way, all others be cast into the Pit" is a straw man. But if you are using Haskell, then it's not too far off the truth, but also not a big deal, because once you're comfortable, they're quite convenient.Zankoku Okunonoreply@blogger.comtag:blogger.com,1999:blog-5722310642266356003.post-80028270180626725572014-07-12T22:07:56.480+02:002014-07-12T22:07:56.480+02:00What an utter retard! It's an old post I know ...What an utter retard! It's an old post I know but you, sir, are a complete and utter retard. Please stay away from programming languages.z0ltannoreply@blogger.com