skaller wrote:
>> language:
>> 1.2: olabl-like labels/keywords
>>
>
> We have named fields, the syntax is just messy:
>
> f struct { x = 1; y = 2; }
>
> works now, provided f is written to accept a suitable record type.
>
>
Err, I meant adding sugar for label support :)
>> 1.3: multimethods
>>
>
> Not sure these make sense.
>
I'm a big fan of the lisp multimethods for their object system, and I
think it'd tie in pretty nicely into the felix typesystem. If you're
unfamiliar with the term, wikipedia has a nice writeup:
http://en.wikipedia.org/wiki/Multimethods.
My favorite example for multimethods is the collision problem. If we
were approaching things from an OOP perspective instead of the
traditional FP pattern matching, we'd want to walk a scene graph and
take two generic objects and check if they collide. In traditional
single dispatch, we'd use the visitor pattern to determine the type of
the two objects, and call a more specialized colliding function.
Multiple dispatch can avoid this for us by using an implicit
map/subtyping to do this for us. So we could do something like this (in
pseudo-felix):
fun collide(x:Shape, y:Shape) = // generic bounding box collision
fun collide(x:Box, y:Box) = // optimized box collision
fun collide(x:Sphere, y:Shape) = // optimized sphere-bounding box collision
fun collide(x:Sphere, y:Sphere) = // optimized sphere collision
fun collide(x:Sphere, y:Box) = // optimized sphere-box collision
And the dispatcher would automatically determine the most specific match
between the two objects.
>> 2.0: metaprogramming
>>
>> some way to rebind vals (this would be useful, but skaller already said
>> it's not doable. Maybe we can figure out a reduced form to cover some of
>> the use cases)
>>
>
> Felix already has several powerful metaprogramming facilities.
> Including ordinary polymorphism, HOFs, macros, preprocessor,
> user defined syntax.
>
> I have an idea to turn Barry Jay's pure pattern calculus
> into an impure calculus (polluted by Felix terms).
>
> Care needed: 'metaprogramming' is a bogus idea. It's a
> way of giving up on what is really required: better
> polymorphism.
>
I should have been a bit more clear. I meant the whole metaocaml-like
quoting. I only have a little experience with the felix macro system.
Can it fill this role?
>> 1.1.3: __LINENO__, __FILE__ macros
>>
You rock. Thanks for adding this so quickly.
>> 2.0: writing a llvm backend
>>
>
> This is unlikely until llvm makes an amd64 backend.
>
True. However, llvm also can generate c code, which could be a nice stopgap.
>> 2.0: interpreter
>>
>
> Which one? We could perhaps embed Neko .. but not
> while it is using Boehm gc. Lua has it's own gc,
> but Lua is a bit ugly ..
>
> What we really want is dynamic compilation of Felix
> into shared libs, which are then loaded.. that's hard
> to do (the type safety seems like an open problem ..)
>
I was actually thinking of llvm's bytecode and interpretation. They
already have a jitter, and should be able to do a repl. It's a bit lower
level than neko, so we can easily provide our own gc. Finally, they are
developing a sizable community (the main dev works at apple and is paid
to develop llvm for them), so it's pretty active.
>> 2.0: direct felix debugging
>>
>
> Yup .. well something anyhow :) My thought is to put
> a TCP/IP based debugging service into the driver.
> Written in Felix I guess ... :)
>
>
>
One more llvm advantage. Their bytecode already supports all sorts of
debugging info. So, if we went llvm, it'd be pretty easy to get
debugging support.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
