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,
Fernando Mato Mira <········@iname.com> writes:
>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 Mogensen (·······@diku.dk)
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].
Thanks,
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.
Pieter Koopman
Hello!
In article <·················@iname.com>,
Fernando Mato Mira <········@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.
Regards, Hannah.
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>
From: Fernando Mato Mira
Subject: macro characters (was: Lisp syntax for Haskell?)
Date:
Message-ID: <377A22B0.99DF9A64@iname.com>
> 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.
Actually, this should read "do not pollute the namespace so one can carelessly
use SET-MACRO-CHARACTER as we please on ? ! and so on".
Hello!
In article <·················@iname.com>,
Fernando Mato Mira <········@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>
Regards, Hannah.
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
)
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/
Hello!
In article <·················@iname.com>,
Fernando Mato Mira <········@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.
>[... infix in Lisp ...]
>Little example:
> #I(a[i] = b[u + foo(u,v) ^^ z],
> i += 1
> )
>http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/
Hmmm. Looks very imperative, but anyway, I've now learnt that such
extensions are possible in Lisp.
Regards, Hannah.
······@schlund.de (Hannah Schroeter) writes:
> 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.
What about this?
- fun rez x = 1 div x;
val rez = fn : int -> int
(in Standard ML of New Jersey, Version 110)
Cheers, Axel
Hello!
In article <···············@clair.dai.ed.ac.uk>,
Axel Schairer <········@dai.ed.ac.uk> wrote:
>······@schlund.de (Hannah Schroeter) writes:
>> 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.
>What about this?
> - fun rez x = 1 div x;
> val rez = fn : int -> int
>(in Standard ML of New Jersey, Version 110)
Where's the contradiction? The SML "shell" compiles the definitions
or expressions you give it (attributing types to it).
You then can't call rez #"a", because #"a" has type char:
- rez #"a";
stdIn:23.1-23.9 Error: operator and operand don't agree [tycon mismatch]
operator domain: int
operand: char
in expression:
rez #"a"
And in contrast to Lisp, that error is raised during compiling, not
during running (when "div" finds out that x isn't of a correct type).
Regards, Hannah.
* Hannah Schroeter wrote:
>> - fun rez x = 1 div x;
>> val rez = fn : int -> int
> Where's the contradiction? The SML "shell" compiles the definitions
> or expressions you give it (attributing types to it).
> You then can't call rez #"a", because #"a" has type char:
You can call rez 0 though.
Hannah Schroeter wrote:
>
> >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.
······@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.
-- jd
* ······@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