That said I haven't had a running install of arc in many years so I could be off base.

Anarki used to use Andrew's library from http://awwx.ws/fromjson (perhaps an older version of your link, i4cu) I switched it out back in 2009 for a faster replacement (https://github.com/arclanguage/anarki/commit/dad4dc6662), not realizing that I was breaking the read side in this rather obvious manner. Since then a bunch of work has happened on emitting JSON, but apparently nobody tried parsing JSON until now.

We could retrofit these bugfixes, but I think it would just give up the speed gains to parse things character by character. May be worth just returning to Andrew's version.

I mean, as long as Racket interop is going to be a thing, maybe using the boolean type isn't a bad idea.

    arc> (if $.#f 'foo 'bar)
    bar
    arc> (if $.#t 'foo 'bar)
    foo

Also, I don't get why the Anarki repository contains a JSON parser implemented in Racket, when the built-in Racket JSON parser works just fine with Arc:

    arc> ($ (require json))
    arc> ($.write-json (obj foo "bar"))
    {"foo":"bar"}#<void>
    arc> (w/instring in "{\"foo\":\"bar\"}" ($.read-json in))
    #hash((foo . "bar"))

It currently works but that's only because json.rkt has been modified.

    (def post-getjson (url params (o port stdin))
      (fromstring (post-url url params) 
        (read-json (port))))

    (def recaptcha-response (s r)
      (post-getjson "https://www.google.com/recaptcha/api/siteverify"
      (list 'secret s 'response r)))

    (def verify-captcha (req)
      (do
        (= resp (recaptcha-response recaptcha-secret* 
        (alref (req 'args) "g-recaptcha-response")))
      (if resp!success 
        (pr "success") 
        (pr "failure"))))

    arc> (w/instring in "{\"foo\": true}" ($.read-json in))
    #hash((foo . #t))

    #hash((foo . t))

I'd like to see perhaps a specific brief example, where using Racket booleans within Arc actually is a problem, because I haven't encountered any myself.

If I try to use the hash from your example in actual Arc code, it works fine:

    arc> (if ((w/instring in "{\"foo\": true}" ($.read-json in)) 'foo) 'yes 'no)
    yes
    arc> (if ((w/instring in "{\"foo\": false}" ($.read-json in)) 'foo) 'yes 'no)
    no

Ah, here's perhaps the only special-case we need to handle:

    arc> (= x (w/instring in "{\"foo\": null}" ($.read-json in)))
    #hash((foo . null))  # expected: #hash((foo . nil)) or #hash()
    arc> (if x!foo (prn "error"))
    error

Actually the Racket docs[0] clarifies the situation with null in JSON:

    (json-null) → any/c

    (json-null jsnull) → void?
      jsnull : any/c

If you set the JSON null to nil before running your example, it works as you'd expect:

    arc> ($.json-null nil)
    #<void>
    arc> (= x (w/instring in "{\"foo\": null}" ($.read-json in)))
    #hash((foo . nil))
    arc> (if x!foo (prn "error"))
    nil

I recommend (obj), (obj foo (list 'null)), (obj foo (list 'false)), and (obj foo (list (list))). Arc is good at representing optional values as subsingleton lists:

  ; Access a key that's known to be there.
  t!foo.0
  
  ; Access a key that isn't known to be there.
  (iflet (x) t!foo
    (do-something-then x)
    (do-something-else))

Meanwhile, I don't think there's any big deal when we don't have Arc-style booleans....

  ; Branch on the symbols 'false and 'true.
  (if (isnt 'false x)
    (do-something-then)
    (do-something-else))
  
  ; Alternative
  (case x true
    (do-something-then)
    (do-something-else))

We do already have booleans that work in Arc without any conversion. Please see http://arclanguage.org/item?id=20492

But now that I look closer at the ac.scm history (now ac.rkt in Anarki), I realize I was mistaken to believe Arc treated #f as a different value than nil. Turns out Arc has always equated #f and 'nil with `is`, counted them both as falsy, etc. So this library was already returning nil, from Arc's perspective.

There are some things that slip through the cracks. It looks like (type #f) has always given an "unknown type" error, as opposed to returning 'sym as it does for 'nil and '().

Really, #t and #f are not proper Arc booleans[0], so it makes sense that Arc can't tell what type they are.

You can configure the value Arc chooses for a JSON null with the $.json-null function, which I think is fine as JSON APIs might have differing semantics.

There are a lot of ways to conceive of what Arc "is" outside of the Racket implementations, but I think Arc implementations like Rainbow, Jarc, Arcueid, and so on tend to be inspired first by the rather small set of operations showcased in the tutorial and in arc.arc. (As the tutorial says, "The definitions in arc.arc are also an experiment in another way. They are the language spec.") Since #f isn't part of those, it's not something that an Arc implementation would necessarily focus on supporting, so there's a practical sense in which it's not a part of Arc our Arc code can rely on.

Really, #t and #f are not proper Arc anything, but the language apparently handles them so IMHO Arc should also be able to know what type they are. Otherwise, I fear, this will become a Hodge Podge language that will lose appeal.

You don't need to add any $ handlers to handle Racket booleans. They can be passed directly to Arc functions.

  (if #f 'foo 'bar)
 

Just my two cents, but maybe you should do some work + commits and get the ball rolling before putting out a call for help on a untouched dead repository of your making. Or even better, pick some of the items from here [1] and start by contributing to Anarki as a community member.

Just have a bunch of things to juggle at the same time. I just thought I'd give a shoutout first.

P.S. I read your post and had a flashback. Eight or nine years ago I was working at a mega corp and couldn't get the company's shared resource team to do any work. At the time I was a BA and had been learning arc in my spare time (as a first language). Long story short I ended up coding an ETL via arc to load annual budget data (template data) from spreadsheets.

The good news was that it worked (no bugs), the bad news was that it was a hack. I lacked two core libraries; One was a spreadsheet-parsing-api library and the other was an oracle DB library. If I remember correctly I created a defop service where people could copy/paste data from the spreadsheet to an input box. Upon submitting the form the data would go through a validator process and return with feedback indicating errors in the data. When successful it would embed the data into a generated SQL string that would be run from my machine via a command line call. All this coded in like 2 days or so.

Although I do consider it a personal project to fix the forum as much as I can and eventually spin off a lightweight, anonymous fork.

http://arclanguage.org/item?id=20272

One thing to consider is that the code is really, really old and was built before cloudflare became a thing. Even the auth code is now fairly outdated (no captcha, no CSRF, etc. etc).

Don't get me wrong it's still useable, but depending on why you're doing this it may not be worth it. If it's to learn arc then swing away, but if I was looking to set up a forum today I's sooner look into installing the open source version of discourse.

edit: also check out shaders post on "Next Steps" [1] and more specifically [2]. Some of these items might overlap with your plans and if so maybe you can put a call out to others already doing the same thing to share in the workload.

Just have to figure out how to parse the JSON response and then integrate it into the forum and recaptcha should work.

It might be useful if it only shows up on the login/signup page after failed attempts, but it might also be overkill. Personally, I prefer overt solutions to opaque ones like shadowbanning and throttling IPs. But mostly it seemed like a good way to figure out some basics (managing keys, how the app server manages the form loop, API responses and JSON.)

I get the impression many of the people who want to start a HN like clone are considering using it as a content delivery platform. For example http://arclanguage.org/item?id=20452 notes a revenue sharing model for specialized content. Now, if that's the case these site owners will have both spammers and content scrapers to contend with. So my initial comment was also referring content scrapers too.

Let me add some info to that.... I'm not sure if anyone noticed, but HN has implemented new session management strategies. You can see this as your login is now maintained across multiple devices, where the arc code (that we have access to) logs you out upon logging in elsewhere. I also believe that when pg handed over the HN code significant changes occurred including how session data is stored and how that data is utilized to integrate with cloudflare. Obviously I'm making big guesses, because I don't have access to the code, but I'm willing to bet the changes HN has put in place would surprise everyone here.

Maybe I am missing something.... Isn't captcha just a fairly simple robot test (and thus preventing spam)? Or are you suggesting something even simpler? Because I've run a few sites and had tried implementing very simple programmatic obstacles and it really didn't stop the spammers.

https://developers.google.com/recaptcha/docs/versions

I know you (akkartik) have a google account, because I remember when you moved your blog over to google's services (I think they call it 'circles' or some such). I also remember you created a news aggregator application that scraped content. Yes, I know, it was a long time ago in a galaxy far, far away..., but still...

I'm thinking that google identified your scraping work and deemed you a risky robot type, but they also probably correlated your IP from the scraping to your IP from your google services login and tagged you that way. So now, even if your IP changed, they'll continue to have you in their cross-hairs for, like, ever.

Other possible reasons:

a) My cookie acceptance policies are non-standard. (I no longer even remember what they are anymore.)

b) I'm often behind a VPN for work.

c) I'm often on my phone, or tethering from my phone.

Complaints about ReCaptcha are fairly common if you look on HN and so on. You don't have to have run a scraper to hit it, I don't think. I think you may be a robot from the future for never having problems with the pictures of signs and cars :p

Yeah I'm aware of the complaints, but in my mind HN wouldn't be the best resource of information for such an assessment. By default HN members are non-standard in most ways that would matter to ReCaptcha.

It's an interesting dilemma and one that I'm coming up on soon as I plan to release a new app in a few months time. In my case the intended audience for the app is very widespread and not specific to a tech audience. It could be that the vast majority of my users (if I get any - lol) would never have a problem, because the vast majority of people using the net don't know what a VPN is or how to change a cookie setting (just as examples).

I'll have to give it some more thought, but in the mean time, are you aware of any resources on the matter that would be more reflective than HN?

edit: I often find info like this [1]:

  "Different studies conducted by Stanford University, Webnographer and 
  Animoto, showed that there is an approximately 15% abandonment rate when the 
  users are faced with CAPTCHA challenge."

However, every step you put users through is a place where your funnel will leak. So in your place I wouldn't turn on captcha until I actually see spam being a problem.

agreed.

> I have zero urge to help maintain it in Anarki

It's really only a few line of code (probably smaller than a unit test) and it has already exposed json bugs, so I consider it a win all around.

I don't know why the tests keep failing, though, it works locally.

I took a look and found fixes for the unit tests. Before I got into that debugging though, I noticed some problems with the JSON library that I'm not sure what to do with. It turns out those are unrelated to the test failures.

Would be seriously cool if the CAPTCHA was implemented in Arc and generated the images locally instead of relying on some Google SASS.

PR = Pull Request.

> Can you link to the post you are referring to?

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).

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.

https://www.reddit.com/r/Clojure/comments/8gfpb3/making_a_da...

> 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.

https://www.quora.com/Does-the-GDPR-apply-to-US-companies

> 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.

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).

    (collect x for x in xs if odd.x)

     (def l (start end)
       (let lis `(1)
         (pop lis)
         (while (<= start end)
           (= lis `(,@lis ,start))
           (++ start))
         lis))

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
          acc.i)))

    arc> (help accum)
    arc> (help for)

That could be a killer feature, but I don't think we have it developed yet. I certainly wouldn't have thought of it. Basically, when I say "killer feature", I'm thinking of the specialization or distinguishing characteristic that we would emphasize in a Quick Start tutorial.

When arc was first launched, the "arc challenge" of building a multi-action website with a form in only ~5 lines of code was the "special feature." Right now, I think hackability and simplicity of the syntax are two of the better things, but we could probably specialize on more.

> IMO doing package integration first is putting the cart before the horse

The purpose for working on package integration is to enable further development. Without the ability to share code easily, it's a lot harder to build on and benefit from community effort. In itself, I agree, a package manager is boring and probably not a killer feature. However, making it really easy to start building something useful by searching for and loading relevant code straight from the interactive console would be a pretty big step.

> package integration first is putting the cart before the horse

I'm simply saying that features like db integration bring users, users bring manpower, manpower will provide package management in a way that ensures it accounts for more use cases, but again this is moot if what you're interested in is only the language development arena. Though I'm not sure how you could prove out a language unless you can actually use it for real world work.

P.S. If you want users, then killer feature would = todo list mobile app with local db in 30 lines of code!

Absolutely true, which is why I do think the Racket integration is important, so we can just wrap its many and powerful libraries in lighter-weight arc libs, and also why I think a decent package system is important. It needs to be easy to share code, and to find solutions to problems. Otherwise everyone spends too much time rebuilding the same wheels.

> features like db integration bring users

Absolutely. I think better db support in arc would be awesome to have. Especially if we can build an ecosystem where "intelligent defaults" are the norm, so that 90% of the time the exploratory developer can get a db up and running with 1-2 lines.

> todo list mobile app with local db in 30 lines of code

An admirable goal. That's actually a great idea of something we could work toward as a community project, each building pieces that eventually come together to make a decent modern app.

I've just been dumping my Arc experiments into the Anarki repository. Akkartik manages it by the policy that pretty much anyone can commit anything, so I haven't had any issues sharing my code. I've recently put a Puredata compiler in Arc in there, https://github.com/arclanguage/anarki/blob/master/lib/pd.arc

That said, there is an Arc package manager, Hackinator by awwx. http://awwx.ws/hackinator

Perhaps that is worth a look?