an odd suggestion . . .

[thecrackengineer]

First of all, I like this idea very much. I found this Googl-ing the
Web after conceiving of a similar idea in my own head. I hope this
comes to fruition.

Since you may be working on this already, my odd suggestion may be a
bit late. But here it comes . . . .




















(get ready to hurl!) . . . .




















Why don't you make your genner.c or a delegate emit intermediate C
code, while you're trying to figure out the resources and logistics of
emitting targeted assembler? Yes, a bit of an indirect path as there
is some out-of-the-way work to do (emitter, authoring of appropriate
prologues/epilogues, writing of a "pipe chunk" scheduler that can
drive it, et cetera), but it may be worthwhile anyway.
In my mind, this does a few things:
- it might give a faster path to community evaluation of the language
itself, particularly if you chose to not do a multithreaded scheduler
core
- it might provide a future vehicle for code portability of anic (with
a little library help), without requiring targeting for multiple
instruction sets.

a thought. Let the bullets fly.


thecrackengineer

[Duane Johnson]

I would love to evaluate anic. It's been on my radar for some time. Faster paths to that end are always welcome by me :)

Duane

[Daniel Kersten]

Hi,

The question of compiling to C has been asked and answered before. See [1] and [2] for details.

Unfortunately, there has been no public ANI activity in a long time and the last time I spoke to Adrian/Ultimus was just under a year ago. He was still working on ANI at the time, but I would consider the project dead until something is released proving otherwise (ie stay subscribed to the list in case there's any news, but don't hold your breath).

I myself have not done anything ANI related in about a year and a half. I am very slowly working on something kind of similar, but it is not ready to be announced yet and not nearly as ambitious as ANI.

[1]  http://groups.google.com/group/ani-compiler/browse_thread/thread/c6df7e53fecb6433/963c6815f4af7ced 

[2]  http://groups.google.com/group/ani-compiler/msg/28eb06fd0418708f 

Regards,

Dan.

[thecrackengineer]

dkersten, your response is appreciated, thank you.

On the point cited about the desire for ANI to outrun C, I sorta
conveniently disposed of that for this discussion. It is an important
goal, though, if the language is to be worth its salt.

And on the point cited about the uniqueness of ANI's IR, I did
anticipate that whatever emitter were made to do this would have to
build some very non-intuitive C code precisely to deal with the
runtime semantics that are alluded there . . . and as dkersten says,
it is understandable that they are necessarily unique . . . but I
don't think it's completely impossible, either. There would be one
hefty scheduler involved in this, though.
I do think that after all is said and done with the emitter, that code
written in ANI and converted to C will probably be slightly slower
than a manually multithreaded piece of C built to do the same thing to
the same multitasking granularity.

Another problem with a C conversion is the lack of awareness of
processor (hardware threading) elements on the platform. C scheduler
would have to handle this in an agnostic way. More heft for that
scheduler.

Just trying to kick some life into this thing. So far it sounds like
I'm kicking a dirt bag.
That's not to criticize dkersten or Duane here, though . . . thanks
for the replies!

dkersten, can you tell me where and how to expect the announcement of
your new project?


thecrackengineer

On Jan 7, 5:17 pm, Daniel Kersten <dkers...@gmail.com> wrote:
> Hi,
>
> The question of compiling to C has been asked and answered before. See [1]
> and [2] for details.
>
> Unfortunately, there has been no public ANI activity in a long time and the
> last time I spoke to Adrian/Ultimus was just under a year ago. He was still
> working on ANI at the time, but I would consider the project dead until
> something is released proving otherwise (ie stay subscribed to the list in
> case there's any news, but don't hold your breath).
> I myself have not done anything ANI related in about a year and a half. I
> am very slowly working on something kind of similar, but it is not ready to
> be announced yet and not nearly as ambitious as ANI.
>

> [1]http://groups.google.com/group/ani-compiler/browse_thread/thread/c6df...

>
> [2]  http://groups.google.com/group/ani-compiler/msg/28eb06fd0418708f
>
> Regards,
> Dan.
>

[Marshall Lochbaum]

I would be happy to write an interpreter for the language. That's a project that shouldn't take more than a few weeks, given the light weight of the specification. It wouldn't be fast or even multithreaded, but it would let us work with the language, which is really important for making sure that the design makes sense. It really would be a shame to spend a few years on a compiler and need to tack on poorly thought-out features later.

Marshall

[David Samuelson]

Any progress or updates on an interpreter?

[Marshall Lochbaum]

I never started, given that nobody seemed interested in the results. Another problem is that there isn't a complete specification of the language. The tutorials are good, but they're missing a LOT of things (I haven't looked at them in a while, so I can't give examples right now...). I can probably put something basic out in the next few weeks, though. I'll update this list on progress in that direction.

Marshall

[Daniel Kersten]

Some example where the documentation is incomplete:

There is this question: http://news.ycombinator.com/item?id=4382149

If you read the section on constant latches in the tutorial, it hints at the mechanics, but stops short of really explaining how they work under the hood and it doesn't really answer the question in that comment.

There seem to be a few places where the tutorial touches on a concept, but stops short of a proper deep explanation (its a tutorial, after all, not a deep technical analysis of the language).

Other areas that were never explained in detail is how the runtime should schedule streams. The compiler (would have, if it ever got finished) compiled streams into blocks of code and it was the runtimes job to schedule them to run when they become unblocked (the streams and latches they depend on receive data), but the mechanics of this - how it determines which order runnable tasks are to run in (remember, Adrian wanted ANI to be deadlock-proof) - was never explained.

Memory management was another one that was only touched on here on the mailing list. How is dynamic memory provided to a program? How does the garbage collector work, if there is one (I believe Adrian said he didn't want garbage collection and think he wanted linear types instead - I personally agree with that idea). Are values immutable?

To build real life programs, you need lots of powerful data structures and abstractions. The tutorial introduced a binary tree, but I feel there isn't enough documentation there to really show the mechanics of non-stream data structures or how to build them. For example, using the information we have available, how would you go about building a hash table?

Basically, all we have two small example programs (dining philosophers and the clock calculator), a tutorial that touches on the concepts behind ANI, but doesn't really delve into any deep details (and seems to be incomplete at that), an incomplete introduction to how the runtime was to function and an FAQ that only barely touches on technical details.

We're missing more detail on.. everything, we're missing a complete listing and/or reference of builtin/primitives, we're missing information on memory management and how to build data structures, we're missing (IMHO) sufficient details on how the runtime operates.

For this reason, I suggest that if we want to get an ANI-like language, we take the ideas and concepts provided here, but otherwise start from scratch. That way we can fill in the gaps in ways that makes sense to our language, rather than trying to patch together ANI's gaps in ways which we don't really know make sense as a whole because we don't know what research, work or tests Adrian went through to arrive at what we have now. Then when we have a complete spec, we implement an interpreter - forget about compiling (JIT or AOT), forget about faster than C, keep parallelism in mind, but not required for version one. The sooner there is a working interpreter, the sooner people can explore the language and the ideas and write real code (which will lead to more example code, something we are sorely lacking in the current version of ANI).

Finally, if we were to do that, we would need to change the language somewhat anyway to fill the gaps, so I suggest that the syntax is also revised to eliminate the bits that people seem to see as pain points. I understand the reasoning behind Adrian's decisions, but I don't think we need to or should stick to it exactly, lets not alienate people too much. The two main issues I would personally like reworked is the \ (I personally don't mind it, but its something a LOT of people complain about, so lets change it) and the fact that most of the language flows left to right, yet some flows right to left. Lets stay consistent and make everything left to right.

Example:

index = [int\\] <- {0,1,2,3,4,5,6,7,8,9};


\\index ("Hello, World #" + .. + "!\n") ->std.out;

Line one is right to left, line two is left to right.

But if we are changing these things anyway, lets at least look into the possibility of basing the syntax off something like Python or Ruby. We don't have to go that route, but lets not dismiss it right away without exploring it first. If the language were made at least a little bit more familiar (and less like Perl line-noise code golf... I know the semantics are different from other languages and that's why Adrian wanted to keep the syntax very different, but I think a middle ground exists) then I think it will be easier to get more people interested than if it looks like APL.

So.. what do you think? Shall we take a stab at this or does my idea not make much sense?

Regards,

Dan.

[Daniel Kersten]

err, where I said streams, I meant pipes. Where I said blocks, I meant pipe chunks. May as well use the ANI terminology.