Arc Forumnew | comments | leaders | submit | zck's commentslogin
3 points by zck 25 days ago | link | parent | on: About lobste.rs

I've never signed up for lobste.rs. Could I get an invite? What do you need to invite me? (email in profile)

reply

3 points by akkartik 25 days ago | link

I'll invite you.

reply

3 points by zck 25 days ago | link

Thanks! I'll spend some time checking it out. :)

reply

3 points by zck 35 days ago | link | parent | on: With and withs

Similarly to this, when I'm writing Java, I use `final`^1 everywhere I can. It's nice to be able to know that anywhere later where the variable declared final is in scope, it will have the same value as at the point it's set. I don't need to look through any code to see if it's rebound; I know it hasn't been.

[1] "final" is kind of like "const", if I understand `const` right. `final int x = 3;` means that it is an error to later have the line of code `x = 4;`.

reply

2 points by zck 40 days ago | link | parent | on: Installation on windows?

I wish arc had better integration with Emacs. I'd love a SLIME/Cider-style integration. With infinite time, I'd like to write one.

reply

3 points by zck 40 days ago | link | parent | on: Vouch

> Maybe is just needs to be dead first.

Yeah, if you have enough karma, you can see "vouch" links on dead submissions. The easiest way to see this is to go to https://news.ycombinator.com/newest; many of those links will be dead.

reply

3 points by hjek 38 days ago | link

So you need to have `showdead` enabled for vouch to ever be visible, I guess?

reply

4 points by zck 45 days ago | link | parent | on: Anarki Reference Documentation

Very cool! I might make some changes, like links, categories, a TOC.

Obviously feel free to make any of these; I'm not sure when I'll get to them.

reply

3 points by rocketnia 43 days ago | link

Yeah, these would be great! I focused on shipping something, but there are many ways it can be improved. :)

reply

4 points by zck 52 days ago | link | parent | on: Separation of concerns

> Run the unit tests.

Certainly a lot of things could be tested more; this would help.

But also, we might want to set Github to require the tests to pass on a PR before letting it be merged. I could be wrong, but I think a PR can be merged even if the tests fail.

This is a slight step away from "anyone can commit anything", I acknowledge. But it's also a step towards stability. At least the person would have to fix or delete the failing tests before merging.

reply

5 points by rocketnia 52 days ago | link

Fixing other people's test breakage is one of the only things I can do for Anarki that doesn't make me feel like I'm breaking things myself. :-p

reply

4 points by zck 50 days ago | link

Well, it's a great help! Writing tests can help too, but just being around and helping is wonderful.

reply


Arc is definitely not going to be able to use IOLib. If you want to find some libraries, you might be able to use some Racket libraries.

I'm not sure if you're looking to write the server component, or the code that contacts the server.

If you want to make a webpage that returns the current date and time, it's either straightforward or complicated, depending what exactly you want.

If you want a webpage that returns the current date and time _in UTC_, it's straightforward:

    arc> (thread (serve 8080))
    #<thread>
    arc> ready to serve port 8080
    arc> (defop hello req (let (sec min hour day month year) (timedate) (prn year "-" month "-" day " " hour ":" min ":" sec)))
    #<procedure: g20474>
If you want it in your local timezone, that's more complicated. You might have to pull in Racket libraries.

-----

3 points by akkartik 92 days ago | link

I just went through this exercise as well. Once you define the server, you can then query it with this code:

    arc> (load "lib/client.arc")
    arc> (cdr (mkreq "http://localhost:8080/"))

-----

3 points by zck 92 days ago | link

Ooh, interesting! We might want to figure out a long-term documentation system for Anarki; the existing arclanguage.github.io documentation is for Arc 3.1. And while that's great, it's suboptimal for cases like this, because it says "...there is no support for outgoing network connections." (https://arclanguage.github.io/ref/networking.html).

-----

2 points by akkartik 92 days ago | link

Yeah, there's a reason why the documentation isn't linked on the right side at http://arclanguage.github.io :/

-----

3 points by christianbryant 92 days ago | link

How about UDP calls? I sucked this CL snippet a while back (sorry I don't have the author info at hand). Creates a socket, sends data and receives data:

  (defun create-client (port buffer)
     (let ((socket (usocket:socket-connect "127.0.0.1" port
					 :protocol 
                                         :datagram
					 :element-type 
  '(unsigned-byte 8))))
    (unwind-protect
	 (progn
	   (format t "Sending data~%")
	   (replace buffer #(1 2 3 4 5 6 7 8))
	   (format t "Receiving data~%")
	   (usocket:socket-send socket buffer 8)
	   (usocket:socket-receive socket buffer 8)
	   (format t "~A~%" buffer))
      (usocket:socket-close socket))))

-----

2 points by hjek 66 days ago | link

Check the Racket docs on UDP[0]. Arc itself is very high-level, but you can do more low-level stuff via Racket interop.

[0]: https://docs.racket-lang.org/reference/udp.html

-----

2 points by christianbryant 92 days ago | link

Appreciate it. I want to just write the code that contacts the server. Some Python pseudocode to represent the basics is below, but that just represents basic socket foo, minus the code for authentication, etc. The code would run through a list of 20+ systems and just connect one by one and log that system's local datetime. The assumption is we're doing UDP communication.

  client = socket
  host = local_system
  data = datetime_query
  remotedata = datetime_response
  target = remote_system

  client.connect (remotehost, port)
  client.send (data, target)
  remotedata.receive (remotedata, host)

  if remotedata:
	print 'Remote system date and time is:', remotedata
	else print 'No data received.'

-----


Also on reddit: https://www.reddit.com/r/lisp/comments/8z34az/anarki_communi....

-----

3 points by zck 256 days ago | link | parent | on: Next steps

> My first thought is a package system based on melpa / use-package from emacs.

That would be great! Use-package is amazing, and that (combined with similar loading things from package.el) could make loading dependencies way easier. I know that when I'm writing arc code, I'm reluctant to use libraries -- even libraries included with arc -- because they're (afaik) impossible to automatically load.

> We could also experiment with some avant garde packaging ideas, such as akkartik's thoughts on avoiding version pinning...

Amusingly, the Emacs ecosystem can be thought of as a package manager that avoids version pinning; the standard package repositories (GNU Elpa, Melpa) only keep the latest version of a package around; you can't install older versions.

Of course, I know of no package foo.el that introduced _foo2.el_ when breaking backwards compatibility. So we can maybe do better that way.

-----

3 points by zck 266 days ago | link | parent | on: Oldest Arc Forum item - 10 year anniversary

Whoa! Pretty cool find. I keep hoping the community has some sort of comeback, but I'm not really sure how. Not to be too much of a downer -- I do really like so much about the design of Arc.

-----

4 points by shader 261 days ago | link

It shouldn't be too hard if we provide some real reasons for people to use the language. A 'killer app' if you will.

That and production-readiness, so that they don't have to stop using their favorite 'toy' when they want to build something real. Some of that involves just making more libraries available.

Maybe starting with the package-management / CI system that pulls directly from github akkartik and I were discussing earlier. It would be cool, not too hard to implement, and make sharing libraries a lot easier.

-----

4 points by shader 261 days ago | link

This is where a more traditional forum system would be beneficial. I know we've done lots of work on module / package systems in the past, but it's not easy to do research on it. Maybe we could use github issues on anarki to discuss some of these topics?

I did find lib/ns.arc, which rocketnia had done apparently back in 2011...

Modules and packages are related, but can be implemented independently. The package system is just for discovering and fetching code. Modules keep it separate and help avoid mistakes caused by interface overlap. Honestly, we can probably do without modules if we're careful - for example, emacs doesn't have namespaces, just a prefix convention.

Not having modules does make arc seem more like a toy than a production system though. You're more at the mercy of the remote developers.

-----

4 points by hjek 258 days ago | link

Personally I find that the 'killer feature' is Racket integration as Racket has quite an extensive well-documented standard library (and FFI so that's all C libraries as well).

Even if Arc doesn't get much attention itself, it still benefits from the work going into Racket.

So there are a lot of libraries available. (Arc's Racket integration still has a few rough edges, particularly regarding keyword arguments, but there are workarounds.)

One interesting library is this video editing DSL, http://docs.racket-lang.org/video

-----

2 points by shader 258 days ago | link

That doesn't really qualify as a 'killer feature' for Arc; it doesn't provide any incentive for someone to learn and use Arc - and keep using it - over just learning Racket in the first place.

I do agree that it dramatically improves the value of Arc over being written as a stand-alone interpreter. And providing easier access to Racket features may be a good idea. It helps bootstrap Arc, like Clojure on the JVM with the Java standard libraries until proper clj wrappers are written.

-----

3 points by hjek 256 days ago | link

I do know some Racket, and for me this exact feature did provide an incentive for me to learn and use Arc, because I could apply what I already knew.

Arc feels more brief and less strict, so in some cases it's more pleasant to use than Racket.

When I found out about Arc's Racket interop a couple of years ago, I was really surprised that this was not documented anywhere, so I added a section in the Readme.

-----

3 points by shader 255 days ago | link

I agree it's important, and we should probably develop it and make it easier because it's an important foundation. However, there aren't that many Racket developers, and its not really the best argument in favor of using a language that it just happens to be a better version of another language. That might be a competitive advantage against Racket, but what about compared to other interpreted languages? Why would someone want to use arc over Python or Ruby?

> When I found out about Arc's Racket interop a couple of years ago, I was really surprised that this was not documented anywhere, so I added a section in the Readme.

Yeah, the documentation could use some work. Definitely not our competitive advantage at the moment, though that could be changed if we build on our interactive help system.

Also, that feature is really only part of anarki. I don't think arc3.1 had that feature. I think at this point it seems like pg has pretty well abandoned arc though, so maintaining compatibility shouldn't be a primary concern.

-----

2 points by akkartik 255 days ago | link

Hmm, I don't think pg has abandoned Arc. And I don't think maintaining compatibility is a concern even so. So far Arc has made no compatibility guarantees. We're all forking pre-alpha software. So it's conceivable the hundred-year language will have features from Anarki. Forks that restrict where they get good ideas from will be outcompeted by forks that don't.

Though lately I consider it more likely that a hundred-year language will have a leveled-up conception of "compatiblity", one that assumes orders of magnitude more forking activity. (See "the Zen of Mu" at the bottom of http://akkartik.github.io/mu; Mu is my attempt at building out the foundations for a hundred-year stack. With, perchance, something like Arc on top.) Perhaps Arc shouldn't be a single language but a family of forks (https://lobste.rs/s/n0d3qo#c_rue8pf). Not a single tree but a clonal colony (https://en.wikipedia.org/wiki/List_of_longest-living_organis...). That'll only work if we can make it easy for superficially-incompatible forks to exchange features and functionality back and forth. Which is an unsolved problem so far. So we may well be very far from a hundred-year language.

Anyways, this tangent is my contribution. I don't have a short-term answer for how to solve Arc's users-vs-libraries chicken-and-egg problem ^_^

-----

4 points by shader 255 days ago | link

> I don't have a short-term answer for how to solve Arc's users-vs-libraries chicken-and-egg problem ^_^

Be the change you want to see in the world... I'm not really sure how to motivate the community, but I am rather attached to it, even if I have been a very infrequent lurker over the past years. We have had a relatively high amount of discussion over the past few days though...

I don't think we can just expect to flip a switch and suddenly get a community; we have to /be/ a community, and then people might be willing to join us.

-----

3 points by shader 255 days ago | link

Maybe we should emphasize the flexibility of our language designs by making the language itself more modular. It would be challenging from a compatibility/dependency standpoint, but those are problems we might have to solve anyway. It would help to have better isolation of components.

-----

2 points by hjek 254 days ago | link

I agree.

Some newbie friendly documentation to ns.arc would be great, or perhaps some very simple examples. Have you tried using ns.arc?

https://github.com/arclanguage/anarki/blob/master/lib/ns.arc

-----

2 points by rocketnia 251 days ago | link

It looks like I might've subtly broken ns.arc with my own changes to make Anarki installable as a Racket package. Here's an example that should be working, but currently isn't:

  ; my-file.arc
  (= n 2)
  (= my-definition (* n n))
  
  
  arc>
    (= my-definition
      (let my-ns (nsobj)
        
        ; Populate the namespace with the current namespace's bindings.
        (each k (ns-keys current-ns)
          ; Racket has a variable called _ that raises an error when
          ; used as an expression, and it looks like an Arc variable, so
          ; we skip it. This is a hack. Maybe it's time to change how
          ; the Arc namespace works. On the other hand, copying
          ; namespaces in this naive way is prone to this kind of
          ; problem, so perhaps it's this technique that should be
          ; changed.
          (unless (is k '||)
            (= my-ns.k current-ns.k)))
        
        ; Load the file.
        (w/current-ns my-ns (load "my-file.arc"))
        
        ; Get the specific things you want out of the namespace.
        my-ns!my-definition))
  4
  arc> n
  _n: undefined;
   cannot reference an identifier before its definition
    in module: "/home/nia/mine/drive/repo/mine/prog/repo/not-mine/anarki/ac.rkt"
    context...:
     /home/nia/mine/drive/repo/mine/prog/repo/not-mine/anarki/ac.rkt:1269:4
The idea is, you create an empty Arc namespace with (nsobj), you use `w/current-ns` to load a file into it, and you use `a!b` or `a.b` syntax to manipulate individual entries.

An "Arc namespace" is just a convenience wrapper over a Racket namespace that automatically converts between Arc variables `foo` and their corresponding Racket variables `_foo`.

For some overall background...

I wrote ns.arc when I didn't have much idea what Racket namespaces or modules could do, but I was at least sure that changing the compiled Arc code to more seamlessly interact with Racket's `current-namespace` would open up ways to load Arc libraries without them clobbering each other. It wouldn't be perfect because of things like unhygienic macros, but it seemed like a step in the right direction.

I went a little overboard with the idea that Racket namespaces and Racket modules could be manipulated like Arc tables. However, that was the only clear vision I had when I embarked on writing the ns.arc library, so I approximated it as well as I could anyway. In fact, I don't think the utilities for generating first-class modules (like `simple-mod` and `make-modecule`) are all that useful, because as I understand a little better now, Racket modules are as complicated as they are mainly to support separate compilation, so generating them at run time doesn't make much sense.

I'm still finding out new things about what these can do, though. Something I didn't piece together until just now was that Racket has a Racket has a `current-module-name-resolver` parameter which can let you run arbitrary code in response to a top-level (require ...) form. I presume this would let you keep track of all the modules required this way so you can `namespace-attach-module` them to another namespace later. Using this, the kind of hackish partial-namespace-copying technique I illustrate above can probably be made into something pretty robust after all, as long as Anarki sets `current-module-name-resolver` to something specific and no other code ever changes it. :-p

-----

3 points by rocketnia 240 days ago | link

I tinkered with Anarki a whole bunch and finally got this working smoothly. There was a missing step, because it turns out we need to load certain Racket-side bindings into a namespace in order to be able to evaluate Arc code there. It seems more obvious in hindsight. :)

I approached this with the secondary goal of letting a Racket program (or a determined Arc program) instantiate multiple independent intances of Anarki. The ac.rkt module was the only place we were performing side effects when a Racket module was visited, and Racket's caching of modules makes it hard to repeat those side effects on demand, so I moved most of them into a procedure called `anarki-init`.

By adding one line to the example I gave...

  (= my-definition
    (let my-ns (nsobj)
      
      ; Load the Arc builtins into the namespace so we can evaluate
      ; code.
      (w/current-ns my-ns ($.anarki-init))

      ...))
...it becomes possible to evaluate Arc code in that namespace, and the example works.

I used issue #95 on GitHub to track this task, and I talk about it a little more there: https://github.com/arclanguage/anarki/issues/95

Before I started on that, I did a bunch of cleanup to get the Anarki unit tests and entrypoints running smoothly on all our CI platforms. To get started on this cleanup, I had a few questions hjek and akkartik were able to discuss with me on issue #94: https://github.com/arclanguage/anarki/issues/94

A lot of the problems I'm fixing here are ones I created, so it's a little embarrassing. :) It's nice to finally put in some of this missing work, though. I want to say thanks to shader and hjek for talking about modules and packages, provoking me to work on this stuff!

-----

3 points by akkartik 240 days ago | link

And thank you :) I'm glad you got something out of it, because the project's certainly better for it.

-----

3 points by shader 255 days ago | link

> lobste.rs

I was confused for a second or two, because the current top post on that site is almost identical to the one you commented on a year ago.

(What are you working on this week? by caius)

-----

2 points by hjek 254 days ago | link

> Forks that restrict where they get good ideas from will be outcompeted by forks that don't.

That is so true. LibreOffice and Gitea come to mind, but also what happened with io.js/nodejs.

-----

4 points by i4cu 257 days ago | link

I think it is a killer feature in a round-about way. I believe the killer feature is actually generic and robust database integration. There's a whole lot of people who start with data on hand and need to hack together an app from there. The starting point to db integration is racket, which also gets you access to other libraries. Once in place arc libs can be created eliminating a need to even learn racket (just like there are plenty of clojure programmers who don't know java).

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

-----

3 points by shader 256 days ago | link

> the killer feature is actually generic and robust database integration

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.

Perhaps the specialty I'm looking for is exploratory programming, which we've mentioned before. Our interactive help system is pretty good. The only problem others have mentioned before was that Python is arguably better, just because there are already examples and libraries for doing most activities, whereas Arc requires a lot of development effort just to get fundamental components working.

-----

2 points by hjek 254 days ago | link

> Without the ability to share code easily, it's a lot harder to build on and benefit from community effort.

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?

The interactive help in Anarki is great, although there are some undocumented functions. A great improvement, which would be very easy to implement, would be to add the documentation from the various Arc sites to the Anarki interactive help.

-----

3 points by i4cu 255 days ago | link

Well there's that, but honestly... exploratory programming with a tool that can't provide basic functionality will limit how much you can explore. I think you mean 'language design exploration'? - if so I'll stop right there, since, well, frankly... it's not my wheelhouse. :)

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

Cheers.

-----

3 points by shader 255 days ago | link

> exploratory programming with a tool that can't provide basic functionality will limit how much you can explore

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.

Were you thinking a mobile friendly web app, or trying to run it natively on a phone? I'm not really sure how the latter would work... Though building a compatible javascript base for arc would be pretty nice. I do like being able to use consistent code for both clients and servers, as in node and clojure.

-----

2 points by i4cu 254 days ago | link

> Were you thinking a mobile friendly web app, or trying to run it natively on a phone?

The java/js ecosystem has the largest reach making it the easy choice. One could work on a js compiler and target pouchDB as a starting point. That said choosing js also makes Arc go further down the path Clojure has already gone putting the two closer together, and with Clojure being so far ahead in that arena then maybe it's doomed to fail. The other way to go is to do what Clojure is not great at. iOS development? maybe integration with swift? At any rate I'm not a language development guy. I can only tell you what would appeal to me. I mostly use Clojure and a really easy to use arc->iOS app development ecosystem would be really cool.

-----

2 points by hjek 256 days ago | link

> package-management / CI system that pulls directly from github

How would this be different than git submodules?

https://github.com/blog/2104-working-with-submodules

-----

2 points by shader 255 days ago | link

> How would this be different than git submodules?

Most of the difference would be in the user interface. Git submodules might actually be a great idea for how to implement it, to encourage hacking on and submitting changes to the libraries themselves.

Git submodules don't provide a very friendly user experience though. You have to know the repository url and manage them separately. It's not terrible, but it's extra work, and doesn't handle loading the library in your own, or dependency management. Ideally, pulling in a package would also result in pulling in all of its dependencies, without pulling in multiple copies of the same library the way npm used to.

There are a lot more features that could be offered by an actual package system.

-----

More