Arc Forumnew | comments | leaders | submitlogin

I enjoyed watching the video and thought the speaker did a great job, but I can't say I agree with her.

When you start to have spreadsheets that require even a moderate level of analysis, tooling and refactoring then you need to move to a real programming language and environment where you get the benefits of a development eco system that establish application integrity (i.e. user access control & applied methodologies).

I've been involved in projects where companies create these MOASS apps[1] and no spreadsheet or spreadsheet tooling will solve these problems. You may not spend the 'X' months and 'X" dollars to develop the app, but your spreadsheet app will produce incorrect results often and more easily, which will cost you more in the long run (forget the fact that employees will leave which only compounds the problem).

1. Mother Of All Spread Sheets.

This video was very interesting to me: A chance to learn more about functional programming and Excel. Also the speaker was one of the most animated I have seen.
3 points by i4cu 13 days ago | link | parent | on: Arc forum GDPR compliance

After responding in this thread I ventured a little further into what GDPR would look like within the apps I am building and OMG the ability to comply could be horrendously challenging.

For example, some of my apps use Datomic, which contains both an append only log file for data storage as well as bulk storage data facilities provided by 3rd party db systems. And that doesn't even take into consideration indexes. So deleting user data would be a non-trivial exercise.

Simply put: modern day data system architectures have grown in complexity to the degree that you simply just can not push a button and remove user data anymore.

Here's some further discussion if anyone is interested.

P.S. I realize I'm kinda hijacking this thread, and this has nothing to do with Arc anymore, but thought that hjek might be interested (or maybe not lol).

As part of tidying up my code and separating it into individually digestible libraries rather than a big ball of mud, I've started a GitHub organization called "Lathe." [1]

You might be familiar with Lathe as the name of my Arc utility libraries and their namespace system[2]. The concept behind the name Lathe was always related to trying to "smooth out" the language I was working in. (And I think originally it was directly related to the language Blade I was trying to design and build; I was smoothing out Arc to get it closer to Blade, or something.)

And at one point I started putting JavaScript utilities in Lathe as well. At the time, I thought stuffing Arc utilities and JavaScript utilities into the same repo was for the best, because I figured they might interact with each other somehow (e.g. one of them loading the other through an FFI of some kind). They never quite did. Even when I started putting Racket utilities in Lathe, I didn't ever invoke them from Arc or vice versa.

I'm finally breaking Lathe apart into multiple libraries, all under the "Lathe" GitHub organization[1]. I've got these so far:

- Lathe Comforts for Racket (little day-to-day utilities)

- Lathe Morphisms for Racket (algebraic or category-theoretic constructions)

- Lathe Ordinals for Racket (ordinal arithmetic)

Lathe Morphisms and Lathe Ordinals weren't ever part of the original Lathe repo[2]; they're all-new. And there isn't really that much to Lathe Morphisms yet anyhow; its design is still unstable at the most basic levels as I learn more about category theory.

Anyhow, you may notice "for Racket" is part of the library name, and the full GitHub repository name is something like lathe/lathe-comforts-for-racket. I'm organizing Lathe so that it's reasonable to add in libraries like "Lathe Comforts for JavaScript," "Lathe Comforts for Arc," and so on, without having to come up with a creative name for each and every library. :-p

Since Racket has a package repository, I drop the "for Racket" from the name of the library when I publish it there, so people can simply run `raco install lathe-comforts`. I would do the same thing if I were publishing a "for JavaScript" library on npm.

Anyhow, this blog post is a journal of the way I broke out Lathe Ordinals into its own library this week.



I made this blog post about a week ago. It meanders a lot because I'm making up for all the time I haven't been updating my blog.

The gist of it is that the extensible quasiquotation syntax design I've been working on for a while now, which I've thought had something to do with higher category theory, does indeed seem very related.

All the times I've thought to myself "Why is this so hard to implement? Surely someone out there has answers..." it turns out that the people working on opetopic higher categories are exactly the people with those answers. So now some of the complexity that's made me doubt my approach, I can actually be confident about, and I've found some clear answers out there to things I never quite figured out on my own.

For instance, check out "Implementing the Opetopes," a PDF linked from In there, Eric Finster describes a data structure called "SAddr," which is an address referencing a particular part of an opetopic structure, the same way you might use an integer to reference a particular element of a list.

Every so often I would think about what it would take to reference a particular element of what I've been calling a "hypertee," and I would come to the tentative conclusion that I'd need a list of lists of lists ... of lists of empty lists. That's exactly what Eric Finster's SAddr data structure is, so it looks like I don't need to worry that I've made a mistake somewhere; someone else has tested this idea already and had success. :)

Over the past week I've been going ahead with an implementation of the kind of quasiquotation system I've been attempting for all this time. It's going well. :) I look forward to having more to report at some point.

For some background, I've discussed what I'm trying to do with quasiquotation on Arc Forum before, in this thread:

2 points by i4cu 17 days ago | link | parent | on: Arc forum GDPR compliance

Well practically speaking it only applies if there is something the EU can do about it and if you're doing business in the EU they certainly can do something. Even FB, for example, needs to conform otherwise all that ad revenue from EU companies can vanish if the EU governing bodies sees fit to do so.

But the most the EU could do about the Arc forum would be to block EU users from accessing the site (which would be a political nightmare for them in censorship terms). And, in reality, this site doesn't hold any real data worth worrying about and I somehow doubt PG is sitting around worried about what the EU thinks (regarding this site).

None of this has anything to do with what I think of the laws they are creating. Frankly from the little that I've read I kinda like what I see, but still the world doesn't abide by whatever the EU says, as a parallel example... just look at how much trump cares about nafta right now and that's an agreement they signed. (I'm Canadian btw).

Nice write-up.

I think regardless of whether it's really an editor to use on daily basis, it's quite interesting to see any new take on editor keyboard interaction.

My experience:

Of course everyone should use Calc instead of Excel,
1 point by hjek 19 days ago | link | parent | on: Arc forum GDPR compliance

To me, it currently reads more like the GDPR applies when you operate to users in EU,

> The GDPR is applicable to the US entities to the extent such entities process personal data in order to provide a service or a good within the EU territories.

> It doesn't matter if you operate or are established in the EU. If you have EU visitors/users they gain the protections of the GDPR and you have to comply.

2 points by i4cu 24 days ago | link | parent | on: Arc forum GDPR compliance

No one is breaking these laws as the rest of the world is not subject to EU law. Unless you can show the US has adopted the law as a member state then you shouldn't go around stating such things.
1 point by hjek 34 days ago | link | parent | on: Arc forum GDPR compliance

That address doesn't work:

    Final-Recipient: rfc822;
    Original-Recipient: rfc822;
    Action: failed
    Status: 5.4.6
    Diagnostic-Code: X-Postfix; mail for loops back to myself
2 points by hjek 35 days ago | link | parent | on: Arc forum GDPR compliance

I'll give that one a try. Thanks.
3 points by jsgrahamus 36 days ago | link | parent | on: Arc forum GDPR compliance

You might also try
2 points by jsgrahamus 36 days ago | link | parent | on: Arc forum GDPR compliance

I have gotten passwords reset (not sure if it was arc or HN-related) from this e-mail:

Perhaps they could help with this issue, too.


2 points by akkartik 56 days ago | link | parent | on: List comprehensions in Arc

List comprehensions are now in Anarki:

There's really not much happening in CL that can't be achieved in Clojure (or vice versa for that matter). Just grab a library and write your macros to obtain your desired level of brevity/utility. The first thing I did when moving from Arc to Clojure was port over the web service routing along with the html/json generators & parsers. Since then my server code has morphed into a custom unique hybrid, and now when I look at all of these other examples I think ugh, I'll pass thanks.
4 points by akkartik 81 days ago | link | parent | on: List comprehensions in Arc

musk_fan, your initial attempt inspired me to build on it :) Now that we can enumerate from a start number to an end, I hanker after something more comprehensive. Also, after reading malisper's description of iterate at, I thought I'd try to mimic its syntax, in hopes that it'll fit better with a Lisp and be extensible.

Here's what I ended up with: Is the description clear?

2 points by akkartik 81 days ago | link | parent | on: List comprehensions in Arc

Great! A few comments:

1. Is there a reason you start with `(1) and then pop? Why not just initialize lis to nil?

2. Here's a slightly more idiomatic implementation (also more efficient, because it avoids deconstructing and reconstructing lis on every iteration):

    (def l (start end)
      (accum acc
        (for i start (<= i end) ++.i
Read more about accum and for:

    arc> (help accum)
    arc> (help for)
(I'm assuming Anarki in the above example. The Arc version is slightly different.)
3 points by musk_fan 82 days ago | link | parent | on: List comprehensions in Arc

I wrote a simple version that only works like so (l 0 9) == '(0 1 2 3 4 5 6 7 8 9):

     (def l (start end)
       (let lis `(1)
         (pop lis)
         (while (<= start end)
           (= lis `(,@lis ,start))
           (++ start))
The (collect ...) structure is really cool; I'd forgotten about that; it's been awhile since I touched CLisp
4 points by akkartik 85 days ago | link | parent | on: List comprehensions in Arc

Yes, Arc doesn't come with list comprehensions. But it sounds like a fun exercise to build say a collect macro:

    (collect x for x in xs if odd.x)
I think it may be similar to the loop macro in Common Lisp. There's a Common Lisp implementation of loop at (via by malisper)
5 points by i4cu 86 days ago | link | parent | on: List comprehensions in Arc

I don't know python per say, but I don't believe arc supports them. I do know the iterator functions are there for you:

Before he concentrated his coding efforts on APL, I believe that he mostly used Chez Scheme.

He as in the original author.

He's made a point in the past about the utility of being able to see all of your code on a single page, or perhaps just a few pages.

Another interesting page is:

Good to see that your minds have been moving along the same tracks.

Wow, perhaps I should become an APL programmer. (My links below are probably familiar to everyone here, so forgive the shameless replugs. I'm mostly just working through commonalities for my own self.)

"[There is] a sharp contrast between Subordination of Detail and Abstraction as the term is commonly used in Computer Science. Iverson’s notion of subordination is the elimination of notational obligations through the use of generalization, systematic extension, and implicit guarantees. The usual notion of abstraction is the means by which 'API' barriers may be introduced to implement conceptual frameworks that suppress underlying implementation considerations in order to allow a black box reasoning at a different, non-native abstraction level."

I'm very partial to this point, but confusingly I've been calling Iverson's notion of subordination of detail "abstraction", and Iverson's notion of abstraction "service" [1] or "division of labor" [2]. Though lately I try to avoid the term "abstraction" entirely. That seems on the right track.

Regardless of terminology, this is a critical distinction.

[1] [2]


"Common practice encourages decomposing a problem into very small components, and most programming languages emphasize a clear picture of a small piece of code in isolation. APL emphasizes finding ways of expressing solutions around the macro-view of the problem."



Quoting Knuth: *"I also must confess to a strong bias against the fashion for reusable code. To me, re-editable code is much, much better than an untouchable black box or toolkit."

Compare me: "Watch out for the warm fuzzies triggered by the word 'reuse'. A world of reuse is a world of promiscuity, with pieces of code connecting up wantonly with each other. Division of labor is a relationship not to be gotten into lightly. It requires knowing what guarantees you need, and what guarantees the counterparty provides. And you can't know what guarantees you need from a subsystem you don't understand."


OMG, he's talking about "big picture" and "optimizing for the rewrite" I call the latter rewrite-friendliness at And "big picture" is in the navbar on the right of my side.


Ok, that's enough replugging. The most tantalizing idea for me here is to try to get structure to do some of the heavy lifting that names do in more conventional languages.

As a final note, this link somebody showed me today seems really relevant:

As I remember, brevity was one of PG's goals in creating Arc. That thought came to mind as I was reading this article.

I haven't engaged in APL programming but I have done some in other array languages (Klong, J and Q'Nial) and the practice has been enjoyable, not only in getting the answer but also in learning a new way to think/twist one's mind.

4 points by akkartik 118 days ago | link | parent | on: Quitting the arc server

Not at all. I meant that if your server doesn't serve much traffic it'll spend much of its time inside serve-socket blocked on a new connection. It's only after serving a connection that it'll loop around to check quitsrv.

I just ran an experiment, and indeed the server stops after one more request:

    $ ./run-news
    initializing arc..
    ready to serve port 8080
    arc> (= quitsrv* t)
    ; now browse to localhost:8080; page served
    quit server ; printed by *serve*
    ; hit reload on localhost:8080; no response
4 points by noobie 119 days ago | link | parent | on: Quitting the arc server

Thank you for your help!! Could you help me understand what you'd like me to do?

I'm not sure what you think I should try.

After looking up the definition of the 'until' macro, the line of code referenced seems to tell me: if quitsrv* is not nil, then continue to serve-socket, which looks to me, at a noobie's glance, as returning the function "accept-request-with-deadline", opening up threads to serve the request?

i.e., quitsrv* now returns t. According to this definition, doesn't that mean that serve-socket should stop?

And incidentally, when I run more defop macro calls, it returns the 'procedure' but (asv) doesn't work; none of the new page on localhost show up (instead it is "Unknown"). I'll look more into it but not really sure how to proceed after glancing at (def asv).

I've copied down the definitions for while and whilet from arc.arc but they don't seem helpful at first glance. Will look further into them if you think it would be useful.

Thank you!!