Has anybody thought up a Lisp syntax for Haskell? I am about to start learning it, because I think it's the FPL covering most concepts, but I would certainly feel uneasy about accumulating a code base in yet another syntax I'll probably have to switch from in some years.
>Has anybody thought up a Lisp syntax for Haskell? I am about to start >learning it, because I think it's the FPL covering most concepts, but I >would certainly feel uneasy about accumulating a code base in yet >another syntax I'll probably have to switch from in some years.
I have heard of no such thing, but it should be a simple manner to write a program (e.g. in Scheme) that takes a LISP-style syntax and produces Haskell text. The converse is also doable, but somewhat more complex.
Torben AEgidius Mogensen wrote: > I have heard of no such thing, but it should be a simple manner to > write a program (e.g. in Scheme) that takes a LISP-style syntax and > produces Haskell text.
I'm not looking for any implementation. I don't know Haskell yet, and I thought it'd better to ask before I go thinking about something that looks nice, simple, practical, lispy `integrated' and `clash avoiding' (maybe one day someone could come up with a [Common Lisp|Scheme]+Haskell hybrid, for example).
BTW, I'm not really sure whether Haskell the one with more `new things'. Which other ones have monads, for example? [I want to stay pure, otherwise Lisp is already there].
Fernando Mato Mira wrote: > BTW, I'm not really sure whether Haskell the one with more `new things'. > Which other ones have monads, for example? [I want to stay pure, otherwise > Lisp is already there].
See http://www.cs.nott.ac.uk/Department/Staff/gmh/faq.html for an overview. I think Clean is the obvious other candidate when you look for a pure language. It has monads, but does not relay on them for IO. Clean uses its uniqueness type system to ensure that IO actions are well defined, you can use monads if you want.
In article <37734F91.F689F...@iname.com>, Fernando Mato Mira <matom...@iname.com> wrote:
>Has anybody thought up a Lisp syntax for Haskell? I am about to start >learning it, because I think it's the FPL covering most concepts, but I >would certainly feel uneasy about accumulating a code base in yet >another syntax I'll probably have to switch from in some years. >Thanks,
Frankly, I don't see the point of this.
Haskell 98 is meant to be a stable standard, to be supported for a longer time in the future, even while Haskell 2 development continues.
Who knows what will be the language of choice in 5 years? I suppose not Haskell, as fundamental changes in programming paradigms take much more time than a few years. Perhaps it will be a bit more widespread than now, but surely still a niche language. I suppose that the majority languages will still be something imperative, perhaps with more functional elements than now (closures, higher-order functions come to mind, as in Python or in Smalltalk).
And even if you could use a Lisp like syntax for Haskell (something like Sexps), the semantics would still be those of Haskell (i.e. lazy evaluation, referentially transparent, strongly typed), which would not make the move from Haskell (or Sexp-Haskell) to languages like Scheme or Lisp easier.
Hannah Schroeter wrote: > Who knows what will be the language of choice in 5 years? I suppose
`language of choice'? Do you care about C++?
> And even if you could use a Lisp like syntax for Haskell (something > like Sexps), the semantics would still be those of Haskell (i.e. > lazy evaluation, referentially transparent, strongly typed), which > would not make the move from Haskell (or Sexp-Haskell) to languages > like Scheme or Lisp easier.
There're PROLOGs for Lisp. You can interface pure FPs to C libraries. Why not to CLOS? Even if all you had was an embedded Lisp frontend to a pure FP, you could still use the Lisp macro facility prior to translation.
With sexprs, you should be able to switch from one FP to another in a day (modulo special features).
Lisp has been evolving for 40 years and the conventional people keep reinventing more and more of it. <bearded prophet> One they they are bound to reinvent the syntax. `Lisp' is the Computer Language Design Space attractor [we have not converged yet]. </bearded prophet>
Actually, being Lisp syntax so simple, it could well be used as a common interchange format among FPLs (Lisp people would never go through the burden of parsing anything more complicated, and for the other FPLs frontends, it would be little extra work to translate to a common syntax. And they could accept any subset whose semantics they directly support easily. Of course, to make things really practical, the subsets of library interfaces following a similar style should be standardized, which leads us to a common module framework, rules for portable identifiers, etc.)
Anyway, that's a core belief. For me it makes absolute sense, and other base syntaxes do not (I can have infix in Common Lisp. I've used it to pretty much cut&paste Eiffel code and copy math formulas in the few places I needed it). For most FP people is the reverse.
Actually, shouldn't we spice up Lisp in a quote-like way, to make it more practical for pure FP? eg: having !foo mean (strict foo), for example.
<EXTERNAL AND INTERNAL SHIELDS UP - BEAMER STANDBY>
In article <3778CF33.B2C73...@iname.com>, Fernando Mato Mira <matom...@iname.com> wrote:
>Hannah Schroeter wrote: >> Who knows what will be the language of choice in 5 years? I suppose >`language of choice'? Do you care about C++?
I just wanted to say that it is perhaps difficult to predict what languages will be "in" (e.g. you can program for money in them, or they will be taught in programming courses, ...) some years in future.
I don't care about C++, as some luck has spared me that experience till now. However it hasn't spared me programming in C for money (I *hate* manual memory management).
>> And even if you could use a Lisp like syntax for Haskell (something >> like Sexps), the semantics would still be those of Haskell (i.e. >> lazy evaluation, referentially transparent, strongly typed), which >> would not make the move from Haskell (or Sexp-Haskell) to languages >> like Scheme or Lisp easier. >There're PROLOGs for Lisp.
I.e. you have a prolog "subsystem" that you can ask questions or pass new clauses? Then, that's nothing special in my eyes. Or is that meant differently?
>You can interface pure FPs to C libraries. Why not to CLOS?
Yes, you can interface. But what does syntax matter then? You can of course also write OMG IDL and interface CLOS with Haskell with Python with C++ and so on...
>Even if all you had was an embedded Lisp frontend to a pure FP, you could >still use the Lisp macro facility prior to translation. >With sexprs, you should be able to switch from one FP to another in a day >(modulo special features).
I don't believe that. At least for my perception, the greatest hurdle in learning a new FP language is not the syntax, that is learnt rather quickly. It is the switch from e.g. impure to pure, from monadic IO to impure IO or to uniqueness typed IO, from lazy to strict evaluation, from statically typed to dynamically typed, and so on.
>[...] >Actually, being Lisp syntax so simple, it could well be used as a common >interchange format among FPLs
In my view, LISP syntax is simple for the machines (i.e. simple to parse, emit, and so on), but not so for humans. At least I happen to like infix syntax, or even layout (as in Haskell).
>(Lisp people would never go through the burden of parsing anything more >complicated, and for the other FPLs frontends, it would be little extra work >to translate to a common syntax. And they could accept >any subset whose semantics they directly support easily. Of course, to make >things really practical, >the subsets of library interfaces following a similar style should be >standardized, which leads us to a common module framework, rules for >portable identifiers, etc.)
It's still a bit difficult. There's e.g. a fundamental difference between a lazy map function (like in Haskell) and a strict one (like mapcar in LISP). You just use them differently (e.g. efficiency or space usage considerations).
It looks difficult to me to bridge the gaps e.g. between strict vs lazy, statically typed vs. not statically typed, using but one library (framework).
>Anyway, that's a core belief. For me it makes absolute sense, and other base >syntaxes do not (I can have infix in Common Lisp. I've used it to pretty >much cut&paste Eiffel code and copy math formulas in the few places I >needed it).
How do you do it? (I'm not so a LISP geek, as you probably have already figured out...) Reader macros?
>For most FP people is the reverse. >Actually, shouldn't we spice up Lisp in a quote-like way, to make it more >practical for pure FP? >eg: having !foo mean (strict foo), for example. ><EXTERNAL AND INTERNAL SHIELDS UP - BEAMER STANDBY>
Hannah Schroeter wrote: > >There're PROLOGs for Lisp.
> I.e. you have a prolog "subsystem" that you can ask questions or > pass new clauses? Then, that's nothing special in my eyes. Or is > that meant differently?
Lispified prologs. And from what I remember, where you can also call Lisp functions (I only played very little with one years ago, as I've never been into PROLOG).
> I don't believe that. At least for my perception, the greatest hurdle > in learning a new FP language is not the syntax, that is learnt rather > quickly. It is the switch from e.g. impure to pure, from monadic IO > to impure IO or to uniqueness typed IO, from lazy to strict evaluation, > from statically typed to dynamically typed, and so on.
Sure. It's not about _learning_ FP. It's about not having to _relearn_ all that stuff about synthetic language parsing they day you want to move your code to something else. [NLP, _is_ interesting, OTOH. I teached computational (psycho)linguistics before getting into VR]
> In my view, LISP syntax is simple for the machines (i.e. simple to > parse, emit, and so on), but not so for humans. At least I happen to > like infix syntax, or even layout (as in Haskell)
Maybe not for _some_ humans. The value of alternate syntaxes is probably that they appeal to people with different cognitive structures. If you don't provide an alternate syntax, any language is ignoring a certain group of people. In terms of practicality, `logistics' (i.e., all those things one needs to do besides programming in the specific language), a minimalistic syntax wins.
> It's still a bit difficult. There's e.g. a fundamental difference > between a lazy map function (like in Haskell) and a strict one (like > mapcar in LISP). You just use them differently (e.g. efficiency or space > usage considerations).
A form surrounding the code allows you to especify a certain semantics, while still getting to use nice names, eg: (LAZY ... (MAP ... ) .. ) The implementation of LAZY would use local lambdas, or macros as appropriate.
> It looks difficult to me to bridge the gaps e.g. between strict vs lazy, > statically typed vs. not statically typed, using but one library (framework).
What's the precise meaning of `static' here? Nothing prevents a Lisp implementation to support static type declarations (see CMUCL or Stalin, for example).
> >syntaxes do not (I can have infix in Common Lisp. I've used it to pretty
> How do you do it? (I'm not so a LISP geek, as you probably have already > figured out...) Reader macros?
In this case, 1 `dispatching macro char' (a friendly "don't steal more than you need" 2nd-class reader macro if you want) calls up an alternative reader.
Little example: #I(a[i] = b[u + foo(u,v) ^^ z], i += 1 )
han...@schlund.de (Hannah Schroeter) writes: > In my view, LISP syntax is simple for the machines (i.e. simple to > parse, emit, and so on), but not so for humans. At least I happen to > like infix syntax, or even layout (as in Haskell).
I suspect that's a large part of the reason why you "don't see the point" of a Lisp syntax for Haskell.
If you thought that Lisp syntax had important advantages, for both humans and "machines", you might well be able to see why someone might want a Lisp syntax for Haskell semantics.
My point here is not that Lisp syntax *is* better, only that different people have, quite reasonably, different views of the matter; and so what has no point to some might have considerable point to others.
In article <377B3A6C.77622...@iname.com>, Fernando Mato Mira <matom...@iname.com> wrote:
>Hannah Schroeter wrote: >[...] >> In my view, LISP syntax is simple for the machines (i.e. simple to >> parse, emit, and so on), but not so for humans. At least I happen to >> like infix syntax, or even layout (as in Haskell) >Maybe not for _some_ humans.
Point taken. It boils down to personal preference.
>The value of alternate syntaxes is probably >that they appeal to people with different cognitive structures. If you don't >provide an alternate syntax, any language is ignoring a certain group of people. >In terms of practicality, `logistics' (i.e., all those things one needs to do >besides programming in the specific language), a minimalistic syntax wins.
It's probably not so difficult to provide a generator that generates pretty-printed e.g. Haskell source from S-expressions constituting some representation of the abstract syntax of a Haskell program.
>[...] >A form surrounding the code allows you to especify a certain >semantics, while still getting to use nice names, eg: (LAZY ... (MAP ... ) .. ) >The implementation of LAZY would use local lambdas, or macros as appropriate.
Looks good. However, some care must be applied:
In Haskell, every constructor (e.g. (:), which is the same as CONS in LISP) is lazy.
So, if I write some expression finally yielding a list, you should NOT translate it to something like
(lambda () the-list-expression)
as in Haskell, you can evaluate the expression e.g. to walk the spine of the list skipping two cons cells (i.e. you evaluate until you get a cons cell, you DON'T evaluate the head or tail except where needed), and then return the head of the third one. So you evaluate totally three cons cells. You do NOT evaluate the heads of the first two cells, but you do (eventually) evaluate the head of the third (because if you wouldn't need that head, the expression "head of the third cons cell" wouldn't have been evaluated at all).
>> It looks difficult to me to bridge the gaps e.g. between strict vs lazy, >> statically typed vs. not statically typed, using but one library (framework). >What's the precise meaning of `static' here? Nothing prevents a Lisp >implementation to support static type declarations (see CMUCL or Stalin, for >example).
There's a difference between *optional* type declarations and mandatory inferred or declared types. In Haskell/ML/..., EVERYTHING has a type, and if some expression compiles, it is assured that all functions/operators are really applicable to all the arguments they may get passed at run time.
> >In terms of practicality, `logistics' (i.e., all those things one > >needs to do besides programming in the specific language), a > >minimalistic syntax wins.
> It's probably not so difficult to provide a generator that generates > pretty-printed e.g. Haskell source from S-expressions constituting > some representation of the abstract syntax of a Haskell program.
You can prettyprint easily enough, but you usually lose comment layout. In a language (or environment) where comments are important, code transformation isn't viable for this reason.
Regards, Joachim -- Please don't send unsolicited ads.
* han...@schlund.de (Hannah Schroeter) | Who knows what will be the language of choice in 5 years?
the choice of whom? I predict that "one world -- one X" will have been obliterated by then, because Microsoft is not a viable force in 5 years' time, and interesting values of X such as "browser", "language", and "GUI" will go first. after people discover that switching from custom systems to Microsoft to escape Y2K was a leap from the frying pan into the fire, and the lawsuits begin to take down software companies when Congress stops protecting them after seeing the effect of doing so, I also predict that certain design paradigms will suffer greatly. since Common Lisp will go through this process completely unscathed, anyone who chooses to go with a very stable language that has demonsted none of the stupid flaws that cost the world a trillion dollars, or who chooses to market such a language on such premises, will succeed in gigcantic ways -- presuming that this is something they want and are prepared to handle.
so, suppose managers "understand" that Y2K is a language-related problem, and blame whatever popular languages caused serious problems, the way they blamed Lisp when the AI winter set in -- how far will the effect go?
[sorry for the delay in responding, I have had a rare vacation.]
#:Erik -- @1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
