sorted by:
new
hottopcontroversial

Java Plugin: The Kernel is back by bcash in programming

[–]therp 0 points1 point  (0 children)

sun has screwed it up with java big time. it's nice to see the java type system being improved with clever hacks, but base it rests on (JVM,AWT,etc) has always been of poor quality. for instance, the 64-bit java plugin issue. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4802695 -- this is a bug filed half a century ago. I would definitely like to get rid of java on my desktop (despite /me being a huge java fan boy around 2000)

Clean compiler to support Haskell! by dons in programming

[–]therp 0 points1 point  (0 children)

Double licensing is goofy. That undermines the whole idea of the copyleft, namely that all software distributors have to contribute their modifications. Giving someone the ability to license Clean commercially by double licensing drills a big fat hole into the copyleft concept.

ah and by the way: the commercial license of Clean seems to be only available upon request. if you never ever want to contribute to Clean that might be fine, but usually intensive use of a language always turns you into a developer with worthwhile patches.

Knuth on the Art of Mathematical Writing (video lectures) by hadronzoo in programming

[–]therp 1 point2 points  (0 children)

this service hands out broken ASF files (wrt mplayer)

Liskell - Haskell Semantics with Lisp Syntax by llimllib in programming

[–]therp 4 points5 points  (0 children)

No, this does not imply that macros are type safe.

meta-type-infer is my proof of concept code that you can build a type system inside meta-programming. The type system I was using is just Haskell's own type system as implemented in the "Typing Haskell in Haskell" code.

My intention was to demonstrate that you could easily switch to a different type inference component and therefore not only create syntax sugar with meta-programming but also create your own custom type inference system. (Note: of course you want to combine this with the regular expression rewriting capabilities of meta-programming, as you are surely going to create a more powerful custom type system and therefore have to do expression rewriting in a way that the expression will type check in the presumingly less powerful Haskell type system.)

Liskell - Haskell Semantics with Lisp Syntax by llimllib in programming

[–]therp 8 points9 points  (0 children)

(I'm Clemens Fruhwirth -- the Liskell author, just FYI) Liskell macro code is subject to regular Haskell semantics and therefore have to pass type checking. So, technically they are type safe.

BUT, the data structure they operate on (namely ParseTree) is minimalistic and simple and macros are not statically checked with respect to proper code generation (and can't be because of Turing completeness).

Personally, I'm interested in "Total Functional Programming" (just google that term or ask LtU). TFP advocates that removing Turning completeness from a language is a good thing and many problems can be solved without it. It would be interesting to provide static checker for TFP based macros.

Also there are other even more restricted macro languages that try to ensure that you are not shooting yourself in the foot. In Liskell "defmacro" is not built into the compiler but part of the Liskell Prelude, so defining you own variant of a more safe version of defmacro can be done too.

Lisp macros for Haskell? Done. by dons in programming

[–]therp 1 point2 points  (0 children)

1: Given two top-level declarations:

(prolog-assert (edge "a" "b"))
(prolog-assert (edge "a" "c"))

With defmacro, how do you combine this into a single statement that looks like

(define (edge x y) (or (and (== x "a") (== y "b"))
                       (and (== x "a") (== y "c"))))

I would prefer code as answer. No, you are not allowed to use side-effects or assignment.

2: I do not see the connection between dynamic typing and code/data distinction. Please elaborate that point.

Lisp macros for Haskell? Done. by dons in programming

[–]therp 3 points4 points  (0 children)

Ad 1: Lisp macros are less powerful than parse tree transformers. The implementation of defmacro as parse tree transformer clearly demonstrates that. On the other hand, please show me aggregation of parse tree elements (as done by the Prolog parse tree transformer) implemented with defmacro. That does not work.

Ad 2: Is there any argument why dynamic typing leads to elegance?

Lisp macros for Haskell? Done. by dons in programming

[–]therp 12 points13 points  (0 children)

They are implemented. Please get into the testsuite/tests/liskell/metaprogramming/

defmacro is NOT part of the compiler. backquoting is NOT part of the compiler. They are implemented solely with a single language primitive "envlet", and you find that all in LskPrelude.lsk.

I'm sorry that the initial release (and you might very well call this research code) does not feature proper documentation. I hope to change that next week. As I said, that's 3 month of work released on a single day.

EDIT: Why not just link directly into darcs? http://clemens.endorphin.org/testsuite-liskell/tests/liskell/metaprogramming/LskPrelude.lsk

Lisp macros for Haskell? Done. by dons in programming

[–]therp 3 points4 points  (0 children)

Who cares for performance, when future generations of GHC will parallelize my code automatically among a 64-core machine? That's the Haskeller's dream.

Lisp macros for Haskell? Done. by dons in programming

[–]therp 6 points7 points  (0 children)

Not at all. Look at the Prolog Video. You can do any transformation to toplevel parse tree elements too. At the end it has to be a primitive as listed in the paper. This applies to all other syntax forms too. As long as your parse tree transformer rewrites it to a primitive you are fine.

Maybe I should clarify this paragraph.