1. Continuation guards. Should we implement these? The current Arc prevents continuations from a different thread to be executed, as well as protecting continuations from outside 'on-err from being executed within the context of 'on-err.
This is reasonably easy to implement: just have a global "current continuation guard number". Newly created continuations are given that number. If a continuation is called, the current continuation guard number should equal that continuation's guard number. Otherwise we have a call to a continuation outside the guard.
'on-err and 'new-thread would then wrap the function call around something like:
Of course, there's the slight problem of how to handle errors reported by the primitives themselves, as well as the runtime system (such as continuation guards being violated, or doing (car #\newline)). We should call the current 'err error handler.
Also, in canonical Arc, the value received by an 'on-err error handler is an opaque "exn:fail" structure, which Arc cannot manipulate. Should we also emulate this structure?
Not just your directory, the repo is in a mess. I left arc a vibrant cottage industry a month ago, and have returned to a ghost town, it seems :( Can you answer another question of mine?
For a time you could call apply on macros. That ability seems to have fallen off since the support for the call* table. I noticed you tried to add it after, but nex3 reverted the change. I've been struggling to create an entry for macros in call using just two args, without success. It seems the only way is to add an ugly special case into ar-apply. Have you thought about this at all?
Heh, let me know if I'm making no sense, and I'll include commit ids, etc.
parsecomb.arc has not been maintained. The current parser combinator library that is maintained is raymyers's lib/treeparse.arc , but you have to coerce strings to parse into 'cons cells.
For that matter the fix in lib/parsecomb.arc should probably be to mapdelay:
Yeah, that was the first thing I was going to try, then I got sidetracked :)
Can you elaborate on how I can use treeparse for more generalized parsing? Like if I just have a file with flat text and want to generate a list of strings separated by empty lines?
treeparse is very generalized, so expect to write a lot of code.
As for files: the lib/scanner.arc library allows you to treat input streams (e.g. input files) as if they were a list of characters, which is what treeparse accepts (treeparse can work with "real" lists and scanners).
Treeparse usually returns a list of characters, but this behavior can be modified by using a 'filt parser.
Just off the top of my head (untested!):
(require "lib/scanner.arc")
(require "lib/treeparse.arc") ; could use cps_treeparse.arc
(let (list-str newline line oneline lastline allparse) nil
; converts a list of chars to a string
(= list-str
[string _])
; support \r\n, \n\r, \n, and \r
(= newline
; alt & seq's semantics should be obvious
(alt
(seq #\return #\newline)
(seq #\newline #\return)
#\newline
#\return))
(= line
; lots of characters that could be anything...
; but *not* newlines!
(many (anything-but newline)))
(= oneline
(seq line
newline)))
; in case the last line doesn't end in newline
(= lastline
line)
(= allparse
(seq
; many is greedy, but will still pass
; if there are none
(many
; the filter function has to return a list
(filt [list (list-str _)]
oneline))
; might not exist; will still pass whether
; it exists or not
(maybe
(filt [list (list-str _)]
lastline))))
(def lines-from-scanner (s)
(parse allparse s)))
(def lines-from-file (f)
(w/infile s f
(lines-from-scanner (scanner-input s))))
p.s. performance may be slow. cps_treeparse.arc is a more optimized version (maybe 25% faster on average, which most of the speedup in many and seq IIRC, which could be twice the speed), but does not support the "semantics" feature.
Achtung! The CPS variant is written in, of all things, continuation passing style, which is hard on the eyes. It is thus expected to be much harder to read than the straightforward treeparse.
Achtung! In a single Arc session, it is safe to use only treeparse or cps_treeparse. Never load both in the same session.
Achtung! Some of treeparse's features are not supported by cps_treeparse.
doesn't work when s is a scanner -- s remains unchanged. I looked at the code and convinced myself that macros like zap that call setforms won't work for new types. Does that make sense?
Writing libraries is a Good Thing, but trying to create a large collection of libraries for Arc strikes me as a bit of a hopeless cause. After all, Lisp hasn't been able to reach a "critical mass" of libraries and it has many, many more people involved.
I think Arc would be much better off with a way to leverage existing libraries. Easiest would be to use MzScheme's libraries, but that set of libraries is somewhat limited. (I'm currently experimenting with using MzScheme's OpenGL library from Arc; the object-oriented stuff is a big pain since it doesn't play well with Arc.)
Alternatively, if Arc had a way to access the libraries from, say, Python, .Net, or Java, it would gain access to a huge library base. A couple big problems are how to map the language datatypes between the languages, and how to get the runtimes working together.
Maybe make an arc2jvm? Perhaps even arc2java, I'm sure a subset of Java can be made sufficiently C-like to compile down to (and we even get GC for free).
> A couple big problems are how to map the language datatypes between the languages
I'm miles out of my league here, but in the interest of science I grabbed the spec, JSR-223. Here's the juice:
Introduction:
The original goal of JSR-223 was to define a standard, portable way to
allow programs written in scripting languages to generate web content. In
order to do this, it is necessary to have a common set of programming
interfaces that can be used to execute scripts in scripting engines and
bind application objects into the namespaces of the scripts. Therefore, in
addition to a framework for web scripting, the specification includes a
standardized Scripting API similar to the Bean Scripting Framework. It uses
the Scripting API to define the elements of the Web Scripting Framework.
[...]
There are several areas which are intentionally omitted from the
specification:
- The specification does not define how scripting languages should enable
the use of Java objects in scripts, although it is assumed that the
scripting languages implementing the specification have this
functionality.
- The specification does not distinguish between scripting implementations
that compile script sources to Java bytecode and those that do not.
Script engines that do can be used to implement the specification, but it
is not required.
- The specification makes no requirements of scripting languages or the
syntax uses to invoke the methods of Java objects in the languages.
Overview:
In this specification, a scripting engine is a software component that
executes programs written in some scripting language. The execution is
generally performed by an interpreter. Conceptually an interpreter consists
of two parts: a front-end which parses the source code and produces an
internal representation of the program known as intermediate code, and a
back-end which uses the intermediate code to execute the program.
The back-end of the interpreter, also known as the executor, uses symbol
tables to store the values of variables in the scripts.
[...]
Scripting engines which implement the fundamental scripting interface
defined in this specification are known as Java Script l20 Engines.
Conceptually, a Java Script Engine can be thought of as an interpreter, but
this may not actually be the case. For instance scripts executed by a
single Java Script Engine may be executed internally by different
interpreters.
Technologies:
- Java Language Bindings – Mechanisms that allow scripts to load Java
classes, create instances of them and call methods of the resulting
objects.
- General Scripting API – Interfaces and classes that allow script engines
to be used as components in Java applications.
The specification does not deal with issues of scripting language design or
interpreter implementation.
So, it looks like the way you interpret, compile and execute the code is your own business, but if your own ScriptEngine implementation matches the specified API, it will work with existing Java tools and frameworks, particularly for the web. It's modeled after Rhino, so some parts of the Rhino back-end might be directly reusable.
Hear hear! Let there be libraries! The school year's almost over, and I'll contribute more then. And I second the idea of a list of necessary libraries that stefano proposed.
Also, has anyone else found themselves accumulating a file of utility functions? I have one with a little fewer than 30 functions which I find generally useful. There's probably some duplication of standard stuff, but there are also things that aren't. If other people have these, we might put the common functions on Anarki.
I mean scanning Arc files or, better, the help* table and gather information in text files formatted in a wiki-friendly format in order to easily put them on the Anarki wiki.
Edit: have a look at the file lib/help-to-wiki in Anarki (just pushed it).
Ouch, I hadn't thought of that. But I just tested this, and it appears that ac.scm runs the translation step after the xdefed functions return, so we get a valid Arc list back. Saved by the bell, so to speak :)
Why? because there isn't that much in lisp/scheme/arc that comes naturally to me :).
Not sure about how to go about pushing something on something else. Never been in an environment where we worked with cvs or git or anything. Solitary scientists :)
1. This will probably be done in arc2c eventually. Shouldn't be too difficult either.
2. On Anarki the variable 'current-load-file* does this. However the current solution is not thread-safe and having two threads perform 'load at the same time will fail. This means that 'current-load-file* might be changed to a 'thread-local, meaning its contents will be accessed via '(current-load-file* ) - currently it's just 'current-load-file*
3. Someone has to modify infile to do this seamlessly.
1. Yes. This is actually good. You don't want a 1000-iteration loop cluttering a backtrace do you?
Without TCO:
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
in function gs42
....985 more times....
in function foo
in function bar
from top level
With TCO:
in function gs42
in function foo
in function bar
from top level
Less is more?
That said, if you're implementing a state machine using tail-called functions, you lose the trace of the state and can only get the current state (arguably a good thing too - you don't want to have to hack through 600 state transitions, either). You'll probably have to dump the state on-screen or on-disk somehow instead.
2. Yes, this is difficult. IIRC some Schemes actually internally use an abstract syntax tree (not lists) and make macros work on that tree, not on lists. The abstract syntax tree includes the file and line number information.
The problem here is: what do you end up debugging, the macro or the code that uses the macro? If the macro-expansion is a complicated expression, then the bug might actually be in the macro, with the original code quite correct.
In arc2c the file and line number info are lost pretty early. Maybe we could use an AST direct from the file read-in, and silently fool macros into thinking that the AST is a list.
Nope. After all, pg made Arc for hackers, who never make mistakes, and can write an Arc interpreter on bare metal by flipping switches in time to the processor's 100MHz bus clock.
This sounds like a good thing to add to the arc2c compiler anyway ^^. Certainly we could get a backtrace reasonably easily by actually inspecting the closure structures being passed as continuations, but we also have to determine a decent function-to-symbol mapping.
it would be appreciated! :P. Functional programming helps because usually it is the last thing you wrote that is wrong, but occasionally I'm completely puzzled by error messages (only to find out that one of my comments started with a : rather than a ;.
Hmm. Anyway it looks like it might be useful to subtype function closures into continuation and non-continuation functions (as an aside it would probably be useful also for optimizations: when a continuation function exits, it can't be called and its closure can be immediately freed or reused, unless we use 'ccc: and even so we could just copy the continuation into a non-continuation closure).
Then when a backtrace is requested we simply scan through the stack for continuation-type functions, and scan through their closures for continuation-types, and so on until we end up on a closure without any continuation-type functions.
While scanning the stack you have to pay attention to not include functional arguments as if they were called functions. To give descriptive names to functions I would transform every lambda expression in a named function, e.g. :
(def f (x) x) --> (set f (fn (x) x)) --> (set f (__named '(f x) (x) x))
and for anonymous functions:
(fn (a b) (+ a b)) --> (__named '(fn (a b)) (a b) (+ a b))
> While scanning the stack you have to pay attention to not include functional arguments as if they were called functions.
Which is why I was proposing to subtype closures into continuations and non-continuations. Normal functions that are passed around are non-continuations, while continuation closures are created during CPS-conversion. Of course we probably need to add code in 'ccc which would probably copy a continuation closure into a non-continuation version of the closure.
