> java version "1.5.0_06"
> Java HotSpot(TM) Client VM
Yep, you're running Sun. And, now I see that I've been quite foolish (I'm using
Java 1.6) I'll re-compile later today and send you a new copy.
> I'll get back to you. Do you know of any Forth
> derivatives with types?
Well, GForth (and even ANSI Forth) has it:
http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Number-Conversion.html
The problem is, Henceforth is based on Classic Forth (and Machine Forth). Many
of the founding fathers of these two languages consider ANSI Forth to be a
spectacular failure. So I'd proceed with caution if you read anything about
ANSI/GForth.
> I have no idea what Java bytecode looks like.
The following link is pretty readable, but you might need some aspirin anyway.
;)
http://www.javaranch.com/journal/200408/ScjpTipLine-javap.html
> What do you mean by not requiring a compiler? Writing HVM
> bytecode (Format B) by hand? Or format T?
I mean that Format T can be converted to Format B without using a parser. The
ideal use case:
1) I'm running a game on my phone
2) I pause the game
3) I select "script 1" (stored in Format B)
4) I am allowed to view "script 1" as Format T on my phone's screen.
5) I edit "script 1" and save it. (Convert back to Format B)
6) Un-pause.
I Format B were truly compiled, then "viewing" decompiled scripts would be
useless; it'd be something you didn't write.
> I doubt that objects would cause more complication than due
> to dynamic typing and arrays.
Complications, no. But I'm already worried about performance & memory
consumption. And I'm quite worried about dynamic typing.
> something like C structs. And maybe
> methods or Python-style (duck-typing) polymorphism,
> because that is very useful.
> I'm going to ask for a picture from everyone of what
> they think is appropriate.
Yes, I'm curious about that too. If we get typing, structs
might be nice, but I'm not sure about polymorphism (since
there's no notion of "function arguments" in HF).
> Well floating point was just an idea, and wasn't even
> the big idea.
> The big idea is arrays (and especially maps).
Arrays in Forth are easy; just push a series of numbers to the stack. :D
Well... I admit this makes comparing two arrays difficult.
> overly complicated
> specifications that inhibit the implementation of other
> interpreters, but keep things simple/openended where possible.
Oh, I'm just being cautiously optimistic --I'm not trying to rain on your
parade in the least. Actually, I'm really looking forward to see how you guys
manage this in the Standard OHR. So far, HSX is a fairly compact encoding, and
I feel overly positive about any new features, since I know you guys are
actually implementing them too, not just designing them.
All the best,
-->Seth
_______________________________________________
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
