T-expressions are my attempt at answering the question 'what's the minimal clean notation for expressing Prolog terms in S-expressions?'

PicoLisp's Pilog, for example just decides that 'a term is a list'. Which is very clean and simple - but unfortunately it means you can't distinguish between a term AND a list, and it's often very important to tell the two apart.

So the simplest solution is just to reserve one symbol (I use '/' because it's available and not special-syntax on most Lisps... though any symbol would do, and if I were writing from scratch, I might think about repurposing '.') to indicate 'the start of a Prolog-like term'.

The rest of that post series is really just about teasing out some of the implications of this, because I think it opens a lot of interesting possibilities for adding a very minimal notion of 'typed expression' to Lisp. Minimal in that there is no specification of what the meaning of a type is; just that a certain expression is more than just a raw list.

There's a number of applications of this: we can replace almost all special non-S-expression 'reader macro' syntax, for example.

Also having lists which are not Lisp functions/macros means we could implement 'implicit cons', which allows us to drop a lot of complexity in list-builder expressions. For example:

If x were (a b) and y were (c d e) then a standard Lisp expression might look like this:

(cons 1 (cons (car x) (cdr y)))

giving

(1 a d e)

But if we had a Lisp where function calls (or all forms) were term-expression terms, ie prefixed with '/', then we can write that expression as:

(1 (/ car x) / cdr y)

Suddenly we get a lot cleaner notation... fewer nested parens, less awkward syntax, and we can apply this technique to a lot of things.

For another example: say we had a list which was generated from a procedure (local or remote) and we wanted to show that it continues at a remote website:

(1 2 3 4 5 6 7 8 9 10 / more-at-URL "foo.com/bar/part2")

where "more-at-URL" is either a function that evaluates to a list, or just a piece of syntax that's parsed by some higher level.

This is a basic "lazy list" technique, well known to Lisp people for decades.... but the fact that we don't need to hide it behind lambdas, we can do this inline and mark ANY list up with a CDR that is an arbitrary expression, I think is an important capability that is worth thinking about.

I also think that we can then take this syntax and extend it down to the level of formal logic, because what we are essentially doing is writing (slightly extended) First-Order Predicate Logic expressions... and so we might want to think about exact mappings between FOPL and our Lisp expressions. And vice versa: I think we need to look hard at what Lisp, especially the S-expression 'dotted pair' allows us to express that standard vanilla FOPL does not. And ask what that extra piece of information might imply for logic - in the vein of, eg, what the HiLog researchers found, since this is a very similar kind of syntactic extension to FOPL as HiLog is. See, for example, the 1980s Sinclair Spectrum MicroProlog, which uses S-expressions internally to store Prolog expressions, and which discovered the dotted-pair technique for FOPL expressions and called it 'meta-variables'.

Final note: My syntax in the blog posts assumes that I have a custom reader macro and so I don't put a space after the / wherever it appears, in order to make the expressions look a but cleaner... but if you were embedding T-expressions on top of S-expressions in an existing Lisp, you would put a space there. And also you'd need to sort out some way of disambiguating in all cases between /-as-symbol and /-as-syntax. This last bit might be a little tricky.

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.

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

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.

Those people you know who get pissed are either A: not representative of 'the web' or B: not caring enough to stop doing what they are doing. So I will stand by "most of the web does not care" (and yes I am inferring you have to care enough).

> I'd never recommend anyone to use a browser that runs non-free JS.

   "most of the web does not care"

I have to trust that stripe.js is secure - that's what I'm paying them for and if they get a bad reputation like Paypal has then people, including myself, will stop using them and stop paying them. Frankly for a cc payment type script I think their code should be audited by professionals that can see more than just keystroke loggers and if there are any vulnerabilites then the auditors should have the power to shut them down.

If at all you think I'm not on your side I'll suggest you're wrong as:

    * I deleted my facebook account 10 years ago.
    * I deleted my minimal Linked-in account 2 years ago.
    * I don't use an ad-blocker, but I: 
        * make mental notes not to buy their products because the ad pop'd up.
        * don't revisit websites that have ad pop up.
	* avoid sites that have ads.
		

And it looks as though, because I created the account seconds before voting, I failed at least one test in 'legit-user':

  new-karma-threshold* 2

Personally, I see Stripe as being a trustworthy source and I'd much rather use a non-free version from a trustworthy source than a free version from an untrustworthy source. Yeah you can read the code, but no one is going to do that anyways (besides there's more to it than just looking for something nefarious in the code, you also have to make sure there are no missing parts that lead to vulnerabilities and unless you know what the missing parts are....)

I've reread the article and You are right, the author's intention seems to be getting rid of unnecessary constructs. I guess then that I'm looking for something that Arc is not (powerful abstractions included in the language from the get-go).

If you've seen something like the Rust Handbook, that would be one end-goal of documentation I would want to implement. For most other programming languages, there's a multitude of resources available for people to study and learn with. Arc just has a couple of web pages focused towards it, to be honest. We have the tutorial and the various documentation on the different functions of the Arc language.So, I DID spot a couple of web pages, but I'm not so sure if they'll be helpful for new programmers to the language.

    var fibonacci :
        var scope :
            var result = (.argument)
            .argument > 1 then
                set result = 
                    fibonacci (.result - 1) + (fibonacci (.result - 2))
            .result
        scope (.argument)
        
    fibonacci 7

    //result: 13

As you have suggested, a solution for this could be to instead check if the service exist at all in the scope. Service names that do not exist can be assumed to be actions on the @ service. This is a more unconstrained solution. But it means that all actions on @ can never be used as service names. This makes a dilemma between unconstrained, small syntax and prettier code with quirky reserved words. Do you agree?

Now for your other suggestion. Yes, I agree! I have thought about it before, and I think it might have no drawbacks. The fact that you also noticed it makes it even more probable that it is a good solution. The challenge will then be, as you also noticed, how a variable service can be the variable and the value at the same time.

I think it is not good enough to simply check if there are no actions on foo, because then foo must always be the last value. I.e. this has to work:

     foo + 4

Your examples are valid in Linux, but I was trying to launch anarki in Windows. So I've made windows batch file arc.cmd following arc.sh. Seems it works now. I have made a pull req to the repo.

Or, if it all needs to be bundled, you could have symlinks for the libraries you don't change.

If a name's already good, you're not going to change it; if it's bad, you should push that change upstream! (If the name's bad, it's likely that the original author didn't put much time into choosing the name, so I think it would be fairly straightforward to get that merged.)

I'm talking about "a namespace mechanism" here, without actually knowing how one in Arc would work.

Just thinking about it for a moment, I think you'd set the prefix

  (= namespace-prefix 'awesome-package)

  (def /awesome-function (...)
    (...))

  (w/namespace awesome-package
    ...
    (def /awesome-function (...)
      (...))
    ...)

In the end, you have to have some way of avoiding conflicts -- and all of these boil down to tacking something on the front (math.sqrt in python, for instance); I (personally) would rather have a better way of doing this than manually typing out `awesome-package` at the start of every function/macro/variable/whatever.

I think, given that Arc is supposed to be "a language for good programmers" [1], that it's silly to impose restrictions like withholding a namespacing mechanism to encourage a certain type of programming.

Though I like keeping codebases minimal, I also like freedom.

For example:

string-to-number, or string->number, or string->num, or str->num, or ston, or ...

1. Whatever's chosen needs to be consistent (i.e. it should always be "str" -- or "string" -- but not a mix).

2. When choosing, readability and terseness need to be balanced.

(I have a feeling this is really a new discussion, and if this does start to kick off, I'll start a new thread.)