I appreciate the info. I was actually just looking at Mu since I cloned that code for review recently. Since the framework I'll be doing this in is a testing suite, Mu may be the best model for me to follow.

Since I'm focused on UDP, Looking at comments in ac.scm in Arc, I realized MzScheme might hold the answer - there are plenty of UDP functions in those libraries.

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

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

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

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>

I work in Healthcare and we use Eggplant to test a large functional area of our Electronic Health Record (EHR). Like many automation tools, much of the success of the testing comes down to the testing team and how they develop the scripts.

"Software Verification of Orion Cockpit Displays", https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/201700...

Looking back at this project with new eyes, perhaps swapping out Scheme for Arc, I wonder...

My longterm interest is in shifting my mental focus to a more Lisp-oriented way of programming and thinking. I'm not a programmer by trade; I am a software tester and scripter, mostly. I use Python typically, but after working on an OS build I had to learn Guile and Emacs Lisp quickly. I fell in love with Lisp and Scheme due to this experience.

Arc interest came about after reading about it on Paul Graham's website. I'd worked through a portion of Practical Common Lisp by Seibel and decided to try out Arc. It felt right. Since I also happen to work in the Information Security space, I have ideas that for the most part feel like Lisp is the right language, but I will need to become more proficient. Anarki feels like a good place to start to get there from.

However, when I put the folder in D:\Steve - D\Apps\, I got the following: D:\Steve - D\Apps\anarki>arc.cmd default-load-handler: cannot open module file module path: #<path:D:\Steve> path: D:\Steve system error: The system cannot find the file specified.; errid=2

Use Anarki or Anarki's stable branch. The latter is like Arc 3.1 but with a couple of bugfixes.

More details: http://arclanguage.github.io

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

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.

[1] https://github.com/lathe/

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 http://ericfinster.github.io/. 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.