The most common pattern is the "adjacency list" model[0]. Every entry has an ID and parent ID, at least. You can also include an "origin" ID for the root of the tree. For this, you need to build an entire thread with recursive queries (for each ID, get children of ID, etc.) HN and other Arc based forum use this.
Slightly more involved is the "nested set" model[1] which actually maintains a balanced tree. It's easier to query an entire tree than with the adjacency list, but insertions and deletions are more costly.
Basically, each comment has a list of its child comments. Then, when you're going to print out a tree, you recursively also print out child comments.
I think the point of a high-level language is to make your programs shorter. All other things (e.g. libraries) being equal, language A is better than language B if programs are shorter in A. (As measured by the size of the parse tree, obviously, not lines or characters.) The goal of Bel is to be a good language. This can be measured in the length of programs written in it.
[0]https://sep.turbifycdn.com/ty/cdn/paulgraham/bellanguage.txt...;
We'll help you not feel silly when you ask legitimate questions as well as answer them.
"Help me understand how to install arc. When I try to install in racket it says:
racket: undefined; cannot reference an identifier before its definition >"
Here's how I used it for my own issues:
Just after that, Racket introduced an easier way to fix this, `unsafe-set-immutable-car!`, specifically as a stable way to mutate the so-called immutable cons cells going forward. :) We should probably move to that.
I've opened an issue for it: https://github.com/arclanguage/anarki/issues/218
The stable branch has this bug as well.
I'd compare how x-set-car! is implemented in the two versions. Current HEAD: https://github.com/arclanguage/anarki/blob/6f3fecdaa46e25b34...
stable: https://github.com/arclanguage/anarki/blob/stable/ac.scm#L12...
I suspect Racket's changed something in unsafe-set-mcar! during the move to Chez Scheme.
(Sorry I just saw this.)
initializing arc.. (may take a minute)
serving from C:\Users\user\anarki\apps\news
starting app news
load items:
ranking stories.
ready to serve port 8080
To quit:
arc> (quit)
(or press ctrl and 'd' at once)
For help on say 'string':
arc> (help string)
For a list of differences with arc 3.2:
arc> (incompatibilities)
To run all automatic tests:
$ ./arc.sh
arc> (load "tests.arc")
If you have questions or get stuck, come to http://arclanguage.org/forum.
Arc 3.2 documentation: https://arclanguage.github.io/ref.
arc>Living link: https://github.com/arclanguage/anarki/tree/master/lib/racket...
Pinned link: https://github.com/arclanguage/anarki/tree/a2569b1e071bd559b...
In particular, this is /lib/racket-lang-demo/lang-anarki-library.arc, which shows what it would look like to use Racket libraries and other Arc libraries from a `#lang anarki`-based library:
#lang anarki
(:provide anarki-library-export)
(= racket-deep-dependency-export
($:dynamic-require "racket-deep-dependency.rkt"
'racket-deep-dependency-export))
($:dynamic-require "lang-anarki-deep-dependency.rkt" #f)
(load "plain-anarki-deep-dependency.arc")
(= anarki-library-export
(+ "from " racket-deep-dependency-export ", "
lang-anarki-deep-dependency-export ", and "
plain-anarki-deep-dependency-export "!"))
I believe `#lang anarki` does something to make it so `(load "plain-anarki-deep-dependency.arc")` loads the file path relative to the directory the module is in.
There are a number of awkward things about using Arc to write libraries for Racket consumption:
- Racket languages typically have a notion of phase separation where some amount of the program (the compile-time part, i.e., phases 1 and up) happens during the process of compiling a module into a .zo file, and the rest of the behavior (the run-time part, i.e., phase 0) can be performed by loading the already-compiled .zo file. Arc programs are more like `#lang racket/load` in that they only begin macroexpanding the later expressions in the file after they've run the run-time parts of the previous expressions, so it's like the whole macroexpansion process has to wait until run time. The only things `#lang anarki` does at compile time are reading the file's s-expressions and processing the `(:provide ...)` directive.
- Racket and Arc both have macro systems. They both involve writing macro definitions in source-to-source styles that usually make it easy to write a macro that abstracts over another macro call. Sometimes, in more advanced cases, these styles require more attention to get the hygiene right. However, they use different "source" types (Racket's syntax objects vs Arc's plain s-expressions), and they have rather different approaches to hygiene (Racket's lexical information carrying module imports and sets of scopes, vs Arc's gensyms and global variable redefinition warnings). This means mixing Racket macros with Arc macros is one of the advanced cases; I expect that to get the interactions right, it may be necessary to do some explicit conversions between "source" types, as well as being proficient in both languages' approaches to hygiene.
- As far as a module system goes, Arc traditionally has no way to allow multiple pieces of code to see different bindings of the same top-level variable name. (Framewarc and I believe Arc/Nu have approaches to this, but they involve writing all macros differently than before.) Hence, two Arc libraries might fail to be usable together due to mutual clobbering of the same variable, which isn't a typical situation with Racket modules. If and when modular techniques catch on for Arc, those techniques may still be challenging to reconcile with Racket's techniques, so a `#lang anarki`-based library may still not present a very familiar interface to other Racket ecosystem programmers.
- Arc is a lisp-N with its various namespaces, like `setforms`, `defcall`, and `coerce`, stored as entries in global hash tables. Racket is a lisp-N with its various namespaces, like `set!` transformers and `match` expanders, stored on the same compile-time object by implementing multiple interfaces (structure type properties/generic interfaces). This is one particular place where reconciling the modularity approaches may be difficult.
- Racket's compiler tooling tries to determine statically what files a file depends on, both so that `raco make` and `raco setup` can recompile the file if its dependencies have changed and so that if a file is bundled up with `raco distribute` or `raco exe`, its dependencies are included in the bundle. This is something I didn't tackle at all with `#lang anarki`. Things like `load` and `dynamic-require` make it difficult to keep track of dependencies statically this way.
The design I chose for `#lang anarki` was basically to get something tolerable working with as little effort as possible. There's probably a lot of room for improvement, so I didn't consider it stable enough to show off in the `anarki` Racket package documentation.
I think a somewhat better approach would involve:
- Giving Anarki a read-time namespace system like Common Lisp's, to solve Arc's inadvertent name clobbering issues (while potentially still permitting intentional clobbering).
- Going ahead and macroexpanding a whole `#lang anarki` file at compile time, evaluating nothing but the `mac` definitions at first, even though that's not the usual Arc `load` semantics. User-defined macros can sometimes be slow, making it worthwhile to expand them before producing the .zo. Only so much Arc code actually cares about running certain expressions before others are expanded, and those cases can use a CL-style `eval-when` approach.
- Assembling static information about the module just by using `eval-when` compile-time mutable definitions. Then we could dispense with `(:provide ...)` and just have a global mutable table that collects all the exports of the current module.
That tool's results are a little tricky to navigate, but there's a kind of indirect way to turn them into flamegraph SVG images via this library and flamegraph.pl: https://docs.racket-lang.org/profile-flame-graph/index.html
Racket also has some support for getting feature-specific profiling data for certain features, although I haven't tried it for anything yet: https://docs.racket-lang.org/feature-profile/index.html
I think Arc's load time is pretty typical of uncompiled Racket code. In Racket, people can speed up their development process by using `raco setup --pkgs my-package` to compile their libraries or `raco make filename.rkt` to compile individual files. That might be harder to do for Arc, especially the Arc REPL, since Arc's macroexpansion is interleaved with run-time side effects.
I got it to work! I believe akkartik was right. Using command (-c) did the trick, which I assume ensured disconnecting from the database.
(system "psql -U root -d root -c 'SELECT * FROM items'")
item_id | name | type | description | created | location ---------+--------+------+-------------------------------------+----------------------------+---------------------------------------------------- 1 | marble | tool | A small, translucent orange bauble. | 2022年02月23日 17:59:45.480545 | 0101000020E610000012C2A38D239A5EC040683D7C99E44240 (1 row)
(= dbconn (postgresql-connect "root" "root" password))
(table-exists? dbconn "items")oops. It's fixed, thanks.
Maybe it isn't disconnecting?
(tostring (system "psql -V"))
psql (PostgreSQL) 12.9 (Ubuntu 12.9-0ubuntu0.20.04.1)
btw I caught a misspelled 'password' in postgresql-secure-connect:
(mac postgresql-secure-connect (user db ssl-protocol (o passowrd nil))It's a new project. However, Hubski has been using postgres for a few years, but it's currently an amalgam of Arc and Racket. I didn't write the db code, and am trying to start fresh. The Hubski racket connection looks like:
(define db-conn
(virtual-connection
(connection-pool
(lambda () (postgresql-connect
#:user db-user
#:password db-pass
#:database db-database
#:server db-server
)))))
(define db-user "user")
(define db-pass "password")
(define db-database "hubski")
(define db-server "localhost")
Here's my test code that works in the command line, and the response. (I named my db "root" atm and will change that and the user once I get it working. I'm running the app as root.):
arc> (tostring (pipe-to (system "psql -U root -d root") (prn "SELECT * FROM items WHERE name = 'marble';")) )
" item_id | name | type | description | created |
location \n---------+--------+------+-------------------------------------+-- ------------
--------------+----------------------------------------------------\n 1 | marble | tool | A small, translucent orange bauble. | 2022年02月23日
17:59:45.480545 | 0101000020E610000012C2A38D239A5EC040683D7C99E44240\n(1 row)\n\n"
arc>
I even tried to specify the host and port:
(pipe-to (system "psql -U root -h 159.203.186.97 -p 5432 -d root") (prn "SELECT * FROM items WHERE name = 'marble';"))
host all root 159.203.186.97:5432 trust
root@Xyrth:/home/xapp# netstat -tulnp | grep 5432
tcp 0 0 159.203.186.97:5432 0.0.0.0:* LISTEN 124232/postgres
BTW, I am using the domain xyrth.com with a nginx reverse proxy. I just had the thought it may be my nginx configuration. It probably needs to listen explicity on 5432? Here's my current sites-enabled:
server {
listen 80;
server_name xyrth.com;
return 301 https://xyrth.com$request_uri;
}
server {
listen 443 ssl;
server_name xyrth.com;
ssl_certificate "/etc/letsencrypt/live/xyrth.com/fullchain.pem";
ssl_certificate_key "/etc/letsencrypt/live/xyrth.com/privkey.pem";
ssl_session_cache shared:SSL:5m;
ssl_session_timeout 10m;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
location / {
proxy_buffers 16 4k;
proxy_buffer_size 2k;
proxy_pass http://159.203.186.97:8080;
proxy_set_header Host xyrth.com;
}
location ~* \.(png|jpg|tif|ico|ttf|woff|svg|eot|otf|mp3|ogg|wav)$ {
root /home/xapp/static;
expires max;
}
location ~ ^/(xyrth.css) {
root /home/xapp/static;
expires max;
}
}Is this on hubski.com? Have y'all been using postgres there for a long time? Or are you trying it for the first time?
Can you show what command you're running to check that you "can connect to the db from the Arc command line"? I wonder if the app is able to connect but not disconnecting for some reason. That would explain the "thread took too long" timeout message.
If you've written some custom code to connect to postgres, that'd be helpful to look at as well.
It isn't well documented and only tested on a SQL connection but it's just a set of wrappers around Racket's DB drivers, so you could try including that into your app.
Unfortunately I seem to have completely lost my test project but the connection should work as follows:
(= dbconn (postgresql-connect user db password))
The 'lit concept is pretty nice; like tags, but more thoroughly integrated.
I also like the idea of integrating interpreter features more completely, with globe, scope, err, etc.
It raises a question though; how does Bel relate to the Arc community? Is it the full successor? Can they coexist somehow?
Whether you want the community additions or not, you might also be interested in the "official" and "stable" branches of that repo. The "official" branch tracks the official .tar releases that you'd find on the front page here, and the "stable" branch tracks the official releases plus a few small bug fixes and quality-of-life improvements.