In Haskell, for example, everything happens lazily, data is
immutable, there is a complex type system.
Also, if you've already proved the program shouldn't crash due
to type errors, you don't need to check any types as you run.
Actually, you want COBOL. Think about that 
-- vincent
···
On 2011-04-08, at 12:02, Ryan Davis wrote:
On Apr 8, 2011, at 01:34 , Julian Leviston wrote:
...
each{|item| puts item} of split("\n") of to_s of some_data
...No. You want python or (*gulp*) applescript.
AppleScript was my first thought, and this "of" stuff is quite
possibly what I hate the most about trying to do anything in that
language.
···
On Apr 8, 2:02 pm, Ryan Davis <ryand-r...@zenspider.com> wrote:
On Apr 8, 2011, at 01:34 , Julian Leviston wrote:
> Just wondering if this is a possibility?No. You want python or (*gulp*) applescript.
--
-yossef
This is incredibly cool but can you really translate any language into
machine code?
What about languages that are completely different from machine code?
In Haskell, for example, everything happens lazily, data is immutable,
there is a complex type system. Can you really map this right to
machine code? (Or am I misunderstanding your question?)
Thanks
Michal
···
On 8 April 2011 15:03, Josh Cheek <josh.cheek@gmail.com> wrote:
On Thu, Apr 7, 2011 at 11:46 PM, Julian Leviston <julian@coretech.net.au>wrote:
I think it might be actually quite interesting for the original poster to
take some of FONC's work such as OMeta, and then the Rubinius project... and
use it to build Ruby in OMeta, which could then be used quite easily to plug
this Ruby implementation in OMeta into the JavaScript implementation OMeta
which is already existing...For an example of SmallTalk already written in OMeta/JS (ie SmallTalk
running inside Javascript, through OMeta), please see:Given that JavaScript is pretty much the *only* fully realised
cross-browser cross-platform implemented programming language that we have
available to us (ie guaranteed to be on EVERY machine for the last 10
years), and also given that so much work is continually put into making
these interpreters fast and small, I think writing things on top of
JavaScript is a brilliant idea.The other interesting thing about targeting OMeta as an implementation
language for a VM in Ruby, while incredibly technically challenging, is that
it would be infinitely rewarding, as there are versions of OMeta written in
most common programming languages already (which means the target language
base of the Ruby implementation in OMeta would grow without any additional
effort on the part of the programmers)... people are writing OMeta
implementations in various languages, and there are already ones written in:OMeta itself, C#, SmallTalk, Scheme, Lisp, Python and Ruby (I'm fairly sure
there are some written in id.st (or Cola, whatever you want to call it) as
well ;-))Just my two cents.
"You are now able to program any browser in the world with any language you
want"
http://www.youtube.com/watch?v=YEx4jfdFp1kJulian.
That is incredibly cool! But can you really implement *any* language? What
about languages that are completely different from javascript? In Haskell,
for example, everything happens lazily, data is immutable, there is a
complex type system. Can you really map this right to javascript? (or am I
misunderstanding OMeta?)
Of course. Otherwise, the code wouldn't be executed on a CPU, after all.
The question is if you can implement every feature a language has, but
that's more about how much work and workarounds you are willing to
invest (dynamic code is a touch harder, but since there's JRuby which
started before the JVM had any sort of dynamic capabilities at all..),
rather than pure ability.
See also: "Compiler" and "bytecode" or "intermediary language". 
After all, a programming language is a construct, an abstraction, that
allows us to instruct computers to do Stuff(tm), without us having to
lower ourselves to the CPU's level.
The question is kind of like asking if computers can represent text,
or do substraction of irrational numbers, when all they do is binary
addition.
···
On Mon, Apr 11, 2011 at 11:45 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
This is incredibly cool but can you really translate any language into
machine code?
--
Phillip Gawlowski
Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.
Yes but some language features would depend on a run-time library.
The compiler-interpreter dichotomy is better thought of as a continuum.
Bill Rutiser
···
On 2011-04-11 5:45 AM, Michal Suchanek wrote
>
> This is incredibly cool but can you really translate any language into
> machine code?
> What about languages that are completely different from machine code?
> In Haskell, for example, everything happens lazily, data is immutable,
> there is a complex type system. Can you really map this right to
> machine code? (Or am I misunderstanding your question?)
And since it can execute on something as limited and poorly designed
as x86 assembly I see no reason it could not run on OMeta, whatever it
is.
Creating something worse than x86 assembly for running code might be a
sort of a challenge in itself.
Thanks
Michal
···
On 11 April 2011 12:34, Phillip Gawlowski <cmdjackryan@googlemail.com> wrote:
On Mon, Apr 11, 2011 at 11:45 AM, Michal Suchanek <hramrach@centrum.cz> wrote:
This is incredibly cool but can you really translate any language into
machine code?Of course. Otherwise, the code wouldn't be executed on a CPU, after all.
Yes but some language features would depend on a run-time library.
That would be the STG machine I was talking about, which definitely
could be ported.
I'd it'd be easier to first compile Haskell into a bytecode
representation, which you make OMeta interpret. That means you could
use an existing compiler frontend. And just port the run-time library
in OMeta.
TBH for the effort if you wanted Haskell in the browser, it'd
probably be less convoluted to write a plugin. (In Haskell?)
Cheers
Johnny
Sorry, I'm an idiot. Had a brainfart... really you could write a naive
STG machine interpreter in OMeta, which would constitute run-time
support
Equally you could just compile it further.
···
On Tue, 12 Apr 2011 01:53:26 +0900 Johnny Morrice <spoon@killersmurf.com> wrote:
> Yes but some language features would depend on a run-time library.
That would be the STG machine I was talking about, which definitely
could be ported.