Why no equation-based definitions?

[Jan van Mansum]

Hi group,

At the moment I am learning Haskell in my free time as a hobby.
Professionally I am a Java programmer. Being enthusiastic about what
I have seen from Haskell so far I naturally started to look for some
form of "Haskell on the JVM". CAL seems to be pretty close that that
so I hope that in time I'll have the opportunity to learn it and start
using it in my work.

Anyway, my question is why doesn't CAL support the equation-style
definitions from Haskell? I know you can achieve the same effect with
the case-construct in the body of your function, but I thought the
equations especially nice. Is it difficult to implement or is there a
different reason? I hope someone will explain this to a beginner.

Thanks for any helpful comments,
best regards,

Jan van Mansum.

[Meredith Gregory]

Dear Jan,

i've spoken with Bo and Luke and many of the other CALinformians on several occasions. There's nothing in principle that prevents support the equational syntax. Further, there is significant motivation to support it. If CAL could consume a hefty portion of what goes into CABAL (the GHC package system), then CAL could benefit from the exponential growth of CABAL. Then both communities benefit. The Haskell community can export their wares into the JVM world and the CAL people could get a whole bunch of development for "free". It's a win-win situation and baffles me why it isn't a higher priority.

Best wishes,

--greg

--
You received this message because you are subscribed to the Google Groups "CAL Language Discussion" group.
To post to this group, send email to cal_la...@googlegroups.com.
To unsubscribe from this group, send email to cal_language...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cal_language?hl=en.

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

[Luke]

The original motivations for CAL were not to recreate Haskell syntax
exactly, nor even necessarily particularly closely. Rather, we had
some quite specific requirements, driven by teams that were actually
using the language (or more importantly the runtime) from very early
on in the development.

As time progressed, we determined that convenient syntax was
increasingly important as more and more code was expressed directly in
CAL, rather than being programmatically generated inside various Java
apps for various (data processing) purposes.

Even so, we maintained some particular guiding principles in
developing CAL syntax - along these lines:
- Consider adding new syntax when there is distinct value enunciated
by the CAL programmers, and obviously in cases when new language
features require
- Don't add multiple styles for the sake of it but prefer one style
when possible.
- Consider convenient syntactic sugar/contractions when they are
clean, don't risk inducing inefficiencies (or making work for compiler
optimisations we don't clearly know how to perform) and have strong
supporting arguments form developers
- Don't just copy Haskell blindly

Now, like a very many aspects of language development beauty is in the
eye of the beholder. So too are our own particular scruples and
perspectives on the priority of proposed features and comparatives
drawn with Haskell. For myself and the team here, we remain rather
more concerned about CAL as a practical language than we do about how
close to Haskell syntax CAL is. We expect to add features to the
language in the future, but the shortlist is currently more along
these lines:
- Existential Quantification
- Multiparameter type classes with functional dependencies
- Fix higher-kinded types to allow transformers (e.g. t m a)
- Recovery of prefix constructors for tuple types

Further pattern matching features have been discussed in the past.
There are some examples of matching multiple-levels of structure in
regular case analysis (and the local pattern matching declarations)
that have looked desirable for reasons of concision, but we have
always (so far) consistently decided against adding pattern matching
on the l.h.s. of function definitions.

So, in short, I don't see us adding equational syntax ourselves any
time soon, although as Greg says there's nothing preventing its
addition. Of course, being an open source project anyone is welcome
to develop the extensions they particularly like. While equational
syntax isn't a priority for us, if a solid implementation is developed
by others then I would welcome its inclusion in the language.

Cheers

-- Luke

On Feb 18, 5:47 pm, Meredith Gregory <lgreg.mered...@gmail.com> wrote:
> Dear Jan,
>
> i've spoken with Bo and Luke and many of the other CALinformians on several
> occasions. There's nothing in principle that prevents support the equational
> syntax. Further, there is significant motivation to support it. If CAL could
> consume a hefty portion of what goes into CABAL (the GHC package system),
> then CAL could benefit from the exponential growth of CABAL. Then both
> communities benefit. The Haskell community can export their wares into the
> JVM world and the CAL people could get a whole bunch of development for
> "free". It's a win-win situation and baffles me why it isn't a higher
> priority.
>
> Best wishes,
>
> --greg
>

> On Thu, Feb 18, 2010 at 2:21 AM, Jan van Mansum <janvanman...@gmail.com>wrote:
>
>
>
>
>
> > Hi group,
>
> > At the moment I am learning Haskell in my free time as a hobby.
> > Professionally I am a Java programmer.  Being enthusiastic about what
> > I have seen from Haskell so far I naturally started to look for some
> > form of "Haskell on the JVM".  CAL seems to be pretty close that that
> > so I hope that in time I'll have the opportunity to learn it and start
> > using it in my work.
>
> > Anyway, my question is why doesn't CAL support the equation-style
> > definitions from Haskell?  I know you can achieve the same effect with
> > the case-construct in the body of your function, but I thought the
> > equations especially nice.  Is it difficult to implement or is there a
> > different reason?  I hope someone will explain this to a beginner.
>
> > Thanks for any helpful comments,
> > best regards,
>
> > Jan van Mansum.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "CAL Language Discussion" group.
> > To post to this group, send email to cal_la...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > cal_language...@googlegroups.com<cal_language%2Bunsubscribe@google groups.com>

[Jan van Mansum]

Dear Luke,

Thanks for your clear and detailed response. I understand that you
created CAL to solve practical problems and that the idea was not to
create a Haskell compiler for the JVM. Also, the guiding principles
you outlined seem very sound to me. As to the priorities you
mentioned, to be honest, I am too much of an FP beginner to have a
clear idea as to what they are about. Although I would certainly
like to add my favorite Haskell features to CAL, I am probably still
a couple of years away from being able to do so.

I will just take it one step at the time and keep learning Haskell and
CAL when I find the time. By the time I am sufficiently familiar with
it I might be able to contribute something along the lines of a Ant
task or Maven plug-in (if they don't exist yet), things that might
help further the propagation of CAL in the Java world.

Best regards,

Jan van Mansum.

[Luke]

Hi Jan,

Good luck with your Haskell/CAL learning.
I think you'll find learning a lazy functional language very
satisfying and I believe understanding the concepts imbued in these
languages can help make people better programmers - even when they're
still hacking out their C/Java/whatever :-)

-- Luke