Arc Forumnew | comments | leaders | submitlogin
4 points by cchooper 5826 days ago | link | parent

I totally agree that these things should be non-global. In my opinion the grain should be as fine as possible, so that you can use embedded DSLs whenever possible (like w/html or LINQ).

But it's worth pointing out that there are work-arounds to a global read table. In CL, for example:

  #.(install-new-syntax)

  blah...blah...blah...code

  #.(revert-to-old-syntax)
Regarding the use of interfaces to specify the language version: have you ever considered making the language itself a package? The base language could just be a very primitive one, and then everything else could go in a package. It would mean there is no real distinction between 'the language' and 'a package that defines its own syntax'. That feels quite Lispy to me.


4 points by almkglor 5826 days ago | link

> Regarding the use of interfaces to specify the language version: have you ever considered making the language itself a package?

Uh, yes. That's how it's already done. That's why arc.arc is itself a package. In fact, when you say '(in-package foo), the only thing that the contexter will add to the newly-defined package foo are the Arc axioms: '<axiom>fn, '<axiom>if, '<axiom>quote etc. That's why you have to declare '(using <arc>v3) for each package - because otherwise the language doesn't actually import arc.arc

Edit: Ultimately (and this is another disagreement with PG) arc.arc is a library, not part of the language. It's like the libc in this respect. Because you see, we already had the 150-year language 50 years ago.

Edit2: as an aside, the package system even lets you export a binding for 'quote, 'quasiquote, etc. In fact, once we have defined a formal method to add ssyntaxes, it would be possible to add support for `(let foo# ,foo (something foo#)) in a library, not in the language. How? By defining an export for 'quasiquote, say (interface v1 <auto-uniq>quasiquote), where <auto-uniq>quasiquote is a macro that expands to <axiom>quasiquote

> In my opinion the grain should be as fine as possible, so that you can use embedded DSLs whenever possible (like w/html or LINQ).

!!

Hmm. Expression level granularity? Hmm.

-----

1 point by cchooper 5826 days ago | link

Ah yes, I figured because it wasn't in lib/ then it wouldn't be a package.

-----

1 point by almkglor 5826 days ago | link

Hehe. It's in the arc-f/ directory more for historical reasons than because it's not a library, and also because it's treated specially (it gets precompiled to Scheme bytecode, for example).

-----

3 points by almkglor 5826 days ago | link

> But it's worth pointing out that there are work-arounds to a global read table.

How does it handle multiple threads loading code at the same time?

-----

5 points by cchooper 5826 days ago | link

Threads? In Common Lisp? You must be joking!

-----

3 points by almkglor 5826 days ago | link

!!

LOL! ^^ ^_^ >.< ^_^ ROFL!

As an aside, arc-f currently handles loading by wrapping a sizeable bit of 'load in 'atomic, but this is unnecessary, I think, if I use a thread-local for current-load-file* and friends.

-----