SUMMARY: Monday, August 11
Igal Koshevoy
share that we ran out of time and spent hours at the Side Door in
further discussion. I strongly suggest that you go to meetings even when
no presentations are scheduled, because you're missing out on a lot.
Here's what I remember being discussed at the meeting:
UPCOMING EVENTS
Some events that may be of interest to our members:
* International Conference on Functional Programming (ICFP)
[http://www.icfpconference.org/] is September 22-24 in lovely Victoria,
B.C., Canada.
* Linux Plumbers Conference [http://linuxplumbersconf.org/] is September
17-19 in Portland.
IN-MEETING CODING SUGGESTION
I suggested that we can spend a portion of future meetings adding
functionality, tests and refactoring open source applications and
libraries written in functional programming languages. We'd put the
software on a notebook, hook it up to the projector, and let folks
volunteer to turns working on it while discussing how they're solving it
and getting feedback from the group. I think this may be a good way of
stimulating coding and discussion in with practical examples and giving
something back in the process. If you have a project you'd like us to
work on, try to think of what we could realistically do in 30 minutes of
coding to help it, and email your suggestion to the list.
"PILE OF FAIL", v0.2
Bart Massey took another shot at explaining why the object oriented
paradigm is inherently a "pile of fail" and why functional programming
is superior. We put him on the spot, so he gave a talk about this
off-the-cuff -- he'd like to give a more prepared talk about this in the
future. It was a long talk with many side tracks to answer audience
questions, so my notes are sporadic. To the best of my understanding,
his argument was as follows:
* Parnas said that, "Software must be modular." But what's the best
way to accomplish this?
* Different paradigms for writing modular software were tried:
* Imperative module systems, e.g., Modula-3, ADA, etc. These used
very complex static interfaces to define interactions between modules,
which got in the way.
* Object-oriented systems. These used a complex, run-time way of
expressing interfaces and separating isolating chunks of imperative code
and state in a problematic way.
* Functional programming. Provided static interfaces by making
types and functions first class citizens, rather than afterthoughts.
* Functional programming creates more modular code than the
alternatives:
* Treats state as the weird and unusual thing that it really
should be.
* FP code mostly describes the calculations, while OOP code
mostly describes the plumbing needed to shuffle a few scant objects
around and glue to make it sort of work.
* FP is the only one that can provide reflexive, transitive, and
symmetric code, which makes all pure FP code modular.
* Because FP code is more modular than the alternatives, it's a
superior choice for creating software.
CHORTL
Julian Kongslie presented an open source Haskell project called "Chortl:
Combinator Haskell Operators for RTL"
[http://wiki.cs.pdx.edu/forge/chortl.html]. It's a register-transfer
language that helps you describe logic using clear, Haskell code and
then compile it into other languages, such as C and Verilog. This
software makes it easier to design hardware by letting you write the
instructions using a higher-level language that allows for better reuse
and expressiveness. It also makes it easier to simulate logic by
compiling it down to a language like C and testing against it without
having to create chips.
-igal
Phil Tomson
> CHORTL
>
> Julian Kongslie presented an open source Haskell project called "Chortl:
> Combinator Haskell Operators for RTL"
> [http://wiki.cs.pdx.edu/forge/chortl.html]. It's a register-transfer
> language that helps you describe logic using clear, Haskell code and
> then compile it into other languages, such as C and Verilog. This
> software makes it easier to design hardware by letting you write the
> instructions using a higher-level language that allows for better reuse
> and expressiveness. It also makes it easier to simulate logic by
> compiling it down to a language like C and testing against it without
> having to create chips.
>
Oh, man, I missed this one. I'll have to take a look at CHORTL.
Julian, how does it compare with BluSpec or Atom?
Phil
Julian Blake Kongslie
> Oh, man, I missed this one. I'll have to take a look at CHORTL.
Unfortunately, my documentation is rather lacking at the moment, so you
may not find much to look at. But I'm happy to answer questions about
what I have and what directions I want to take it in.
> Julian, how does it compare with BluSpec or Atom?
Well... Chortl reads rather like a block diagram, whereas BluSpec and
Atom read like a collection of rule systems. I made that decision
because I personally care more about filtering and signal processing
circuits without large conditional components but with relatively
complex dataflows.
Like Atom, Chortl is embedded in Haskell. I've abstracted the output
backend somewhat more, so it's (hopefully) relatively easy to write a
new backend and spit out something other than Verilog without
duplicating a lot of compiler logic.
Chortl has a multipass compilation process, almost entirely hidden from
the circuit designer, which allows it to fairly easily support
components like an n-ary multiplier which instantiates as a tree
multiplier of the appropriate size.
I like the way I handle clock domains better than most other RTLs I've
seen, and I have plans to extend the general mechanism I used for some
things like local integer/float format.
Unfortunately, Chortl really isn't *done* yet, and it still doesn't
support the strength of type system that I'd really prefer. In its
current state, Chortl is about as type-safe as Verilog, and I should
really be able to do better.
> Phil
--
-Julian Blake Kongslie
<jbl...@omgwallhack.org>
If this is a mailing list, please CC me on replies.
vim: set ft=text :
Phil Tomson
<jbl...@omgwallhack.org> wrote:
> On Thu, 2008-08-14 at 11:04 -0700, Phil Tomson wrote:
>> Oh, man, I missed this one. I'll have to take a look at CHORTL.
>
> Unfortunately, my documentation is rather lacking at the moment, so you
> may not find much to look at. But I'm happy to answer questions about
> what I have and what directions I want to take it in.
>
>> Julian, how does it compare with BluSpec or Atom?
>
> Well... Chortl reads rather like a block diagram, whereas BluSpec and
> Atom read like a collection of rule systems. I made that decision
> because I personally care more about filtering and signal processing
> circuits without large conditional components but with relatively
> complex dataflows.
So sounds like it's more suited for dataflow (DSP circuits, for
example) as opposed to control logic.
You wouldn't build a CPU with it, for example.
>
> Like Atom, Chortl is embedded in Haskell. I've abstracted the output
> backend somewhat more, so it's (hopefully) relatively easy to write a
> new backend and spit out something other than Verilog without
> duplicating a lot of compiler logic.
>
> Chortl has a multipass compilation process, almost entirely hidden from
> the circuit designer, which allows it to fairly easily support
> components like an n-ary multiplier which instantiates as a tree
> multiplier of the appropriate size.
>
> I like the way I handle clock domains better than most other RTLs I've
> seen, and I have plans to extend the general mechanism I used for some
> things like local integer/float format.
>
> Unfortunately, Chortl really isn't *done* yet, and it still doesn't
> support the strength of type system that I'd really prefer. In its
> current state, Chortl is about as type-safe as Verilog, and I should
> really be able to do better.
>
Let me know if you're going to be doing another talk/seminar on CHORTL.
Phil
Julian Blake Kongslie
> So sounds like it's more suited for dataflow (DSP circuits, for
> example) as opposed to control logic.
> You wouldn't build a CPU with it, for example.
Exactly.
> Let me know if you're going to be doing another talk/seminar on CHORTL.
I think I'll be suggesting Chortl for the next pdxfunc as a project for
in-session coding; there are a few places where it can be rewritten to
be more generic, and some simple features that could be added. I'll be
coming up with a proper proposal to send to the mailing list within the
next few days.