This is fun in that one can do a lot with a small core language. But I also think that core languages may need to evolve, and Lisp expresiveness somehow makes that difficult.
E.g. I think we have a lot to learn from Prolog, Icon, Haskell, Dylan, Erlang, and many others.
> E.g. I think we have a lot to learn from Prolog, Icon, Haskell, Dylan, Erlang, and many others.
Such as?
I know we need to have more Erlang-style VM's. In particular I think we need VM's that pretty much enforce shared-nothing by causing all messages to be copied at the VM level. Hence my current project, which will also tie in some code from the AST-based compiler of arc2c.
As for the other languages... what lessons do we need to learn? I know Haskell makes static type checking really really cool, but I'm not certain if we can bash that into a Lisp. Lisp macros can automagically give you lazy evaluation (you just need to insert special syntax to denote lazy evaluation, in much the same way that Haskell requires special syntax for forced evaluation)
I'm not necessarily thinking in the current Arc,
but in the hypothetical hundred-year Arc.
- Could we make pattern matching through
unification a part of the core language?
- Could we make some tasks easier (I mean
terser) using Icon or Prolog-like
goal-oriented programming?
- Could Haskell typeclasses be adapted to a
dynamic language? (I know that is not possible
in general, but maybe in the most common cases).
CLOS-like oop is the way?
- Easy defstruct as in Haskell is also a win.
- Which would be the best module system?
Python's first order modules are cool, but
I also Haskell's module system seems better
to do ADTs.
- Could we use generators using a lazy
list-like interface?
- To which point could the system be reflective?
In the past it was considered that "flambda"
(user defined, first class special forms)
and redefition of eval with "reflective towers"
are not that good ideas, because of efficiency.
Should we spend more cycles to allow such things?
- Should the read s-expressions also have
associated meta-information?
- Could Arc live in an image?
- Could Arc be just the specification of
its own compiler, making the bytecode
an official part of the language (as
pg once said)?
- Could Arc be blazingly fast?
- Could Arc be prepared for multiprocessor
architectures like the guys (pun intended ;))
in Fortress want it to be? Or to intensive
scalability like Erlang seems to have?
Of course all that questions are implementable.
There probably is a library for every one of them
in Cliki.
I am just asking which of them we should take
and encourage to be seen as part of "Arc's core".
Commonality and practice of an idiom, more than
its mere possibility, is what actually defines
what a language is.
Currently, Arc's core is not much more than sugar for
Scheme (modulo defcall, mostly unseen and great).
This doesn't want to be insultive, I am happy
that people find Arc useful.
Maybe it is that I am looking for a revolution
and Arc is Lisp, which is good but not revolutionary.
> - Should the read s-expressions also have associated meta-information?
IMO yes. It might even be possible to have the meta-information attached to the nearest cons cell instead, so a cons cell might have, say, (cons a d (o line-number) (o file-name)). This makes symbols always equal other symbols without having to worry about attached meta-information for each "symbol".
Might be useful to add in my VM then ^^.
> - Could Arc be just the specification of its own compiler, making the bytecode an official part of the language (as pg once said)?
Interesting. Might be useful to define Arc as a set of macros which just expand to a bunch of bytecode.
Anyway I'm thinking my VM should be "bytecode" based. The bytecode won't have a numeric representation, but it will have a symbolic one, like ((localvar 0) (globalvar foo) (plus))
> - Could Arc be prepared for multiprocessor architectures like the guys (pun intended ;)) in Fortress want it to be? Or to intensive scalability like Erlang seems to have?
Well, this is what I want to do ^^.
> - Could we use generators using a lazy list-like interface?
Scanners? I've actually used scanners for something like this in Arki, the wiki in Anarki.
The Problem with unification and logical variables would be that they have to be dynamic in scope and work with a call-by-name evaluation strategy, at least in Prolog.
Anyway, you could build a Prolog-Like DSL with pat-m and amb
While logic Programming in Arc can make problem-solving easier, i think it introduces problems for libraries:
- How should you call functional functions from logical functions?
- How should you call logical functions from functional functions without violating referential transparency?
- Do closures over logical variables make any sense?
- Should goals be limited in scope? Lexical or dynamic? If I call 2 logical functions from different modules I may or may not want the first to be retried when the second fails, depending on the context.
