Re: [fonc] Hacking Maru

2013-10-21 Thread Tom Novelli
On Mon, Oct 21, 2013 at 1:40 AM, Ian Piumarta piuma...@speakeasy.netwrote:

 I'd love to build a common platform.  Maru is in particular trying to be
 malleable at the very lowest levels, so any special interest that cannot be
 accommodated easily within the common platform would be a strong indicator
 of a deficiency within the platform that should be addressed rather than
 disinherited.


Sounds like an idea I can get behind.  I was writing my own minimal
Lisp/APL compiler but I don't have enough time to do it justice, let alone
build anything (like a little OS) with it.  Never even started GC.  Just
glancing at Maru I'm like yup, I wrote pretty much the same stuff from
scratch. :)

-Tom
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] Compiling COLA on x86_64

2013-10-21 Thread Simon Forman
On 10/20/2013 at 9:38 AM, Ian Piumarta i...@vpri.org wrote:

Simon,

Sorry for the slightly late fixes.  Please svn update your idst 
sources and then make clean in the top-level directory.

On 32-bit Linux make sure you have the packages libreadline-dev 
and execstack installed.
Then type make in the top-level directory.
This will build the st80 libraries for id, the idst compiler 'idc' 
and Jolt.

On 64-bit Linux make sure you have the packages lib32readline6-dev 
(or similar) and execstack installed.
Then type make TARGET=x86_32-pc-linux in the top-level directory.
This will build the st80 libraries for id, the idst compiler 'idc' 
and a 32-bit version of Jolt that can execute its own dynamic code 
on a 64-bit Linux system.

If your Linux does not install execstack in /usr/sbin you may have 
to tweak function/jolt-burg/Makefile in the obvious way.

The VPU version of Jolt is no longer built by default, so...
'cd' to function/jolt-burg and then type ./main.
At the prompt, typing 
(+ 3 4) should give you back a 7.

I've tested this on 32- and 64-bit versions of Linux Mint.

Hope that helps.

(We are certainly not alone in thinking the compiler should be 
part of many a language runtime system. :)

Regards,
Ian


Thank you so much Ian!  I installed lib32readline6-dev and execstack and the 
updated code compiled fine. :)  This is awesome.
Cheers,
~Simon

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc


Re: [fonc] To fork or not to fork? (was: Hacking Maru)

2013-10-21 Thread Ian Piumarta
Loup,

By 'fork' I meant to imply creating a publicly-visible repository that pops up 
in google searches and prevents you finding the place where the progress is 
being made, unless you happen to spot the tiny icon hidden in the corner that 
takes you to the repo from which your current page was forked.  (That's a 
personal gripe and might be blowing my dislike of github, et al., out of all 
proportion. :)  Cloning a repo and experimenting/breaking/repairing in order to 
understand is not the same, nor is using your local Mercurial repository clone 
to work locally and then contribute back to a parent repo.  If that's what Faré 
meant by fork then I'm all for it.

On Oct 21, 2013, at 08:36 , Loup Vaillant-David wrote:

 I'm now doing the same with Earley Parsing[3].

The Wikipedia article's presentation is not the clearest and it is about the 
minimum needed, with some reading between the lines, to make a working 
recogniser.

Earley's thesis and original papers are known to contain errors.  I recommend 
you get hold of Parsing Techniques: A Practical Guide (Grune and Jacobs, 
Springer, 2008) which presents lots of parsing algorithms (including several 
chart parsers) clearly and concisely.  There are a few papers building on 
Earley's work that contain clear presentations of the original algorithm, parse 
tree reconstruction and their compact representations; e.g., SPPF-Style 
Parsing from Earley Recognisers (Elizabeth Scott, Elsevier, 2008) and 
Practical Earley Parsing (Aycock and Horspool, The Computer Journal, 45(6), 
2002).

I agree entirely that after noticing that following the causality of predict 
and scan steps (backwards from the final states) gives all the derivations, the 
rest is relatively easy.

 - Read scientific papers.  I gathered a surface understanding of some
   principles, but nothing solid yet.
 - Build a toy from scratch.  I'll probably do that, since it worked
   so far.

These two are fun to do in parallel.  They feed each other very well.

 Here is how I would imagine my dream world.  It would be a central
 repository with:
 
 - A toy Maru, optimised for clarity.
 - A tutorial for writing your own toy.
 - A serious Maru, lifted up from the toy.
 - A tutorial for lifting your own toy up.
 - The hand-written bootstrap compilers (for understanding, and the
   Trusting Trust problem).
 
 Does this dream world sounds possible? Is it even a good idea?

I hope so, and I think so.  At some point you could consider literate 
programming.  Jones Forth is one example of how this can be attempted even from 
the very first point 
(http://rwmj.wordpress.com/2010/08/07/jonesforth-git-repository).  By the time 
you're on the third step, the above hierarchy could begin to support source 
code representations intended for ease of understanding.

Regards
Ian

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc